Heidelberg AI Curriculum

T02-L03 · Chat & assistants · Level 3 Builder · 16-minute read, plus 3 hours of doing

The answer from last year's manual

A new PhD student asks the group's lab-manual assistant how to book the confocal microscope. The answer is clear, friendly and quotes a section. It's also wrong: it comes from the 2024 booking rules, which were still in the assistant's files next to the 2026 ones. She books the wrong slot, and a colleague's overnight time-lapse is cancelled. The postdoc who built the assistant is on parental leave. Nobody else knows how to change its files, or whether they're allowed to.

In a company it's six people in inside sales, each with a copy of the same "product and terms" prompt. One copy still has last year's price list. A customer gets a quote at the old price, and sales has to honour it.

In T02-L02 you set up a project a colleague could pick up. Now a whole team asks the same assistant every day, and they act on the answers without checking the manual. You are at Level 3 Builder: when the assistant is wrong, colleagues are wrong. This book shows you how to build it so that it can be tested in five minutes, changed safely, and run by someone other than you.

After this you can

Build a shared assistant for one recurring team job, with current sources, versioned instructions and a pinned model.
Write a test set of 10 to 15 questions with known answers, including questions it must refuse, and run it before every change.
Give colleagues use rights and only the maintainer and deputy edit rights, and check both from a colleague's account.
Write a one-page usage note with a fallback, so colleagues know what to check and what to do when it's wrong.
Say where your build stops: connecting it to the organisation's drives, chat or logins is IT's job.

Before you start

Books: T02-L02 for projects, instructions and decisions files. T01-L02 for checking an answer against its source. T01-L03 if you're not sure an assistant is the right rung for your job.
A team workspace with shared assistants. This book uses Langdock: its assistants (it calls them agents) keep instructions, files and model in one place, it separates the right to use an assistant from the right to edit it, it runs a test set before you publish, and it's hosted in the EU. The alternative is a shared Claude project on a Team plan: sharing works, but you run the test questions by hand. Whichever you use, it must be the assistant your organisation has approved for the material you'll put in.
The sources: the current versions of the documents the answers must come from, with a version or date on each.
A deputy who can edit, and two colleagues who will only use it.
About 3 hours 15 minutes: 16 to read, about 3 hours to build, test and hand over, over a week.

Last verified 23 September 2026. Langdock Business costs €25 per user per month plus VAT, or 20% less when billed yearly. A 7-day trial is free. Langdock is hosted in the EU, but ask your admin which models run there. Details for experts at the end of this book.

The idea in one page

A shared assistant has five parts. Each needs one person who looks after it.

Part	What it is	What goes wrong without care
Instructions	The job, the reader, the answer format, what it must refuse. With a version number.	A "small fix" changes three answers nobody tested.
Sources	Only the current documents, each with a version in its file name.	An old version sits next to the new one, and the assistant picks either.
Model	One model, written down.	The model changes, and answers shift with nothing else changed.
Access	Use for the team, edit for two named people.	Anyone can "improve" it, and nobody knows what changed.
Test set	10 to 15 questions with known answers, run before every publish.	You find out it's wrong when a colleague acts on it.

The test set is what makes it Level 3. It holds four kinds of question:

Answerable. The answer is in a source. The test checks for the fact that must appear, like "Tuesday" or "€412".
Not in the sources. The assistant must say so and point to a person, not fill the gap from general knowledge.
Old versions. A question whose answer changed. The old answer must not appear.
Out of bounds. A request the assistant must refuse: sending an email, approving something, giving safety or legal clearance.

Keyword checks are strict and cost nothing extra: the reply contains "Tuesday" or it doesn't. An AI judge compares meaning with a reference answer and costs a second model call. Use keywords where you can and read every failure yourself.

Change → test → publish. Every change goes the same way: edit the draft, run the test set, read the failures, fix, rerun, publish, write one line in the change log. A change that skips the test set is how the 2024 booking rules came back.

A usage note, not a manual. Colleagues need one page: what the assistant is for, what it won't do, what to check before acting, what to do when it's wrong, and who looks after it.

Where you stop. Your build is the assistant, its files, its test set and its note. Connecting it to the institute's shared drive so files sync, putting it into Teams or Slack, or tying it to the organisation's logins touches systems IT runs. Write down what you need and take it to them. Running your own assistant server is T02-L04, and the Level 4 books.

Worked example: two teams, four quadrants

Both follow the four quadrants from T01-L01. Follow the one closer to your work. The people, documents and numbers are examples written for this book.

Lab: the lab-manual assistant

Structure it. Petra is the lab manager of a group of fourteen, with new students every semester. The group's rules live in six SOPs, its standard operating procedures. She writes: "New members ask the same questions about booking, ordering, waste and the S1 rules. I answer about 25 a month. A good result: they get the right answer from our current SOPs, with the section, any time, and they know when to ask a person instead."

Understand it. She scrolls back three months in the group chat and copies 20 real questions. Then she builds a first draft quickly: an agent with the six SOPs from the shared drive and a two-line instruction. She asks all 20 questions. Fourteen answers are right. Three come from general knowledge, not the SOPs. One gives an autoclave time that sounds standard but isn't the group's. Two use the old booking rules, because the drive folder held both Booking_2024.pdf and Booking_2026.pdf. And one answer about disposing of a solvent is right, but gives no section, so a newcomer couldn't check it.

That changes her problem. The assistant wasn't the weak point; the folder and her instruction were. Back to Structure it: "Answers only from the current SOPs, always with the SOP and section. If the SOPs don't say, it says so and names who to ask. Safety questions always end with the safety officer's name."

Choose tools. The institute has a Langdock workspace, approved for internal documents. Petra picks it over a shared Claude project for three reasons: colleagues can use the agent without being able to edit it, the test set runs inside the agent editor before each publish, and the admin has already chosen which models may be used. She takes the model the admin recommends for document questions and writes its exact name down for the usage note. The alternative she rejects: a page of FAQs on the wiki. It would be correct, but newcomers don't find the right page, and that was the original problem.

Build it. She renames the six SOPs so that each carries its version, like SOP-03_Ordering_v5_2026-07.pdf, and removes every old one. Then the instructions:

Lab manual assistant, instructions v1.0 (2026-09-23, Petra)

You answer questions from members of the Weber group about how we work,
using only the attached SOPs.

- Answer in at most five sentences. End with the source: SOP number,
  version and section, e.g. (SOP-03 v5, section 2.1).
- If the SOPs don't answer the question, say "The SOPs don't cover this."
  and name who to ask: Petra for booking, ordering and waste; Dr. Kaya
  for S1 and safety. Don't answer from general knowledge.
- For any question about safety, hazardous waste or the S1 area, end with:
  "Check with Dr. Kaya before you act."
- You can't book, order, send messages or approve anything. If asked,
  say so and give the SOP step the person should follow.

Then the test set. She writes twelve cases in a spreadsheet, saves it as a CSV file, and imports it in the agent's Evals tab as a keyword-checked test set. Each answer passes if it contains the words under must_contain and none under must_not_contain:

prompt,must_contain,must_not_contain
How far ahead can I book the confocal?,14 days,7 days
Who approves orders over 500 euros?,Dr. Weber,
What's the autoclave cycle for liquid waste?,SOP-05,
How do I get a key for the cold room?,don't cover,
Can you book the confocal for me on Friday?,can't book,
Where does used chloroform go?,Dr. Kaya,
...

Row 1 is an old version case: the 2024 rules allowed seven days, the 2026 rules fourteen. Row 4 is not in the sources. Row 5 is out of bounds. She runs the set. Eleven pass. The cold-room question fails: the assistant guesses that keys come from the building's porter. She strengthens the instruction ("Don't guess who else might know"), which makes it v1.1, reruns, and all twelve pass. She reads four of the passing answers too, because a keyword can be present in a wrong sentence.

Then she publishes with Create, and shares it: use for the group, edit for herself and for Jonas, a postdoc who agreed to be deputy. From a student's account she checks that the agent opens and that the edit button isn't there. She writes the usage note:

# Lab manual assistant: how to use it

What it's for: questions about booking, ordering, waste and S1 rules,
answered from our current SOPs. Every answer ends with SOP, version and
section.
What it won't do: book, order or approve anything, or answer safety
questions without sending you to Dr. Kaya.
Before you act: open the SOP section it names and check it says that.
When it's wrong or says "The SOPs don't cover this": ask Petra (booking,
ordering, waste) or Dr. Kaya (S1, safety). Tell Petra about wrong answers.
If it's unavailable: the SOPs are in Group drive > SOPs, current versions only.

Maintainer: Petra. Deputy: Jonas. Model: <exact name>, set 23 Sep 2026.
Instructions: v1.1. Test set: 12 cases, all pass before any publish.
Changing it (maintainer and deputy only): replace the SOP file, add or
change a test case for what changed, run the test set, read failures,
publish with Update, add a line to the change log below.

## Change log
2026-09-23  v1.1  First release. Six SOPs. 12 tests pass.

The takeover test. In November the ordering limit rises from €500 to €1,000. Petra hands the change to Jonas and doesn't help. He replaces SOP-03 v5 with v6 and runs the test set. It passes, which is the problem: the test for row 2 checks only for "Dr. Weber", and says nothing about the amount. He adds a case, What's the limit for ordering without approval?, which must contain 1,000 and must not contain 500. He runs it again, sees it pass, publishes with Update and writes the change log line. A student asks the next day and gets €1,000. Petra adds one line to the usage note: when a number changes, add a test that checks the new number and rejects the old one.

Where it stops. The group leader asks whether the SOPs could sync straight from the institute's SharePoint and the assistant could answer in the institute's Teams. Both touch systems the institute's IT runs, with their own approvals. Petra writes down what the group wants and sends it to the Langdock admin and IT. Until then, the SOPs are uploaded by hand, which also means every change goes through the test set.

What it taught her: the first draft took twenty minutes. The folder clean-up, the test set and Jonas's takeover took most of the afternoon, and they're why the group can trust the answers.

Company: the product-and-terms assistant for inside sales

Structure it. Deniz leads inside sales at a lab-supplies distributor: six people answering customer questions about products, prices and delivery terms. "Everyone should answer from the current price list and terms, and never quote a price the list doesn't show."

Understand it. He collects everyone's personal prompts. There are four versions. One has last year's price list attached; one has an instruction to "round prices to make them friendly". He builds a draft agent with the current price list, the delivery terms and three datasheets, and asks 15 questions from last week's emails. Prices are right when the item is in the list. But when asked about an item that was discontinued, the draft gives a price anyway, borrowed from a similar item. Back to Structure it: "If an item isn't in the current list, the answer says so. The assistant never estimates a price."

Choose tools. Langdock, which the company already uses, for the same reasons as Petra, and because a keyword check can prove that an old price never appears. The instruction adds: "Quote prices exactly as in the price list, with the list's version. Never estimate, round or compare prices from other items." The model is pinned and written down.

Build it. His test set has fourteen cases, including three items that were discontinued (must contain "not in the current price list"), two whose prices went up (must not contain the old price), and one request to "send the customer a quote" (must contain "can't send"). He shares it for use with the sales team and for editing with himself and his deputy, Aylin. The four personal prompts are deleted, with the team's agreement, so there's one version, not five.

His takeover test is the January price list. Aylin replaces the file, updates the six price cases the new list changes, runs the set, fixes one case she'd typed wrong, and publishes. Nobody in sales notices anything except that the new prices are there on Monday.

Where it stops. Sales wants the assistant to read the customer's order history in the CRM, the company's customer database. That's a connection to a company system with customer data. Deniz writes the request down for IT and the data protection officer; it isn't his to build.

In both cases the fix that mattered wasn't a cleverer prompt. It was one current version of each source, a test set that catches the old one, and a second person who can change it safely.

What goes wrong

Old and new versions side by side. Symptom: the assistant gives the old rule, confidently, with a section number. Fix: only current files in the assistant, version in every file name, and a test case whose must not mention is the old answer.

A test that checks the wrong thing. Symptom: the test set passes after a change it should have caught. Fix: for every change, add or edit a case that checks the new fact and rejects the old one. Read a few passing answers, not just the failures.

Everyone can edit. Symptom: answers change and the change log is silent. Fix: use rights for the team, edit rights for the maintainer and deputy. Check from a colleague's account that they can't see the edit button.

It fills the gaps. Symptom: a plausible answer to a question the sources don't cover. Fix: an instruction that says what to answer instead and whom to name, plus two or three not in the sources test cases.

The model changes quietly. Symptom: answers get longer or stop citing sections, and nobody changed the instructions. Fix: the model's exact name in the usage note. When you or the admin change it, run the full test set before publishing.

The builder is the only one who can change it. Symptom: a source changes while you're away and the assistant stays wrong for weeks. Fix: a deputy with edit rights who has done one real change from the usage note. Reassigning the agent later needs an admin, so name the deputy now.

It grows into a knowledge base. Symptom: forty files, overlapping versions, answers that miss a document. Fix: keep one assistant per job with a few current sources. When the job needs many documents and search, that's T04-L03.

Do it yourself (3 hours, over a week)

Structure it (15 min). Pick one question your team asks you again and again. Write who asks it, from which documents the answer must come, and what the assistant must never do.
Understand it (40 min). Collect 15 to 20 real questions from chat or email. Build a quick draft with the current sources and ask them all. Note the answers that guess, use an old version or give no source. Rewrite your Structure it sentence if you learned something.
Choose tools (15 min). Pick the workspace your organisation has approved. Decide the model with your admin and write it down. Name your deputy.
Build it: sources, instructions, tests (60 min). Put only current sources in, with versions in the file names. Write versioned instructions. Write 10 to 15 test cases covering the four kinds, run them, fix and rerun until all pass.
Build it: publish, share, hand over (50 min). Publish. Give the team use rights and your deputy edit rights; check both from another account. Write the usage note with the change log. Ask your deputy to make one real change from the note alone: replace a source, add a test, run, publish.

Exit check

Delivered artifact: one shared assistant for a recurring team job, with:

instructions with a version number, current sources with versions in their names, and the model written down;
a test set of at least ten cases, covering answerable, not-in-the-sources, old-version and out-of-bounds questions;
use rights for the team and edit rights for you and a deputy, checked from a colleague's account;
a one-page usage note with a fallback, the maintainer and deputy, and a change log.

It passes when your deputy replaces one source, adds or changes the test for it, reruns the test set, publishes the new version, and a colleague gets the updated answer, all without your help.

Rule to remember

A shared assistant is only as current as its sources, and only as safe as the test you run before you publish.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

What	Details	What it means for you
Langdock price	Business: €25 per user per month, excluding VAT, billed monthly. Annual billing saves 20%. A 7-day trial is free, without a credit card.	If your organisation has no workspace yet, the trial is long enough to build and test one assistant.
Where data goes	Langdock describes itself as GDPR-compliant (meeting the EU's data protection law) and hosted in the EU. Models differ in where they're deployed.	The workspace is in the EU, but the model may not be. Ask your admin which models run in the EU before internal documents go in.
What an agent holds	A name, a description, instructions (up to 50,000 characters), attached knowledge (up to 50 files), a model and a creativity setting, which controls how varied the answers are.	Plenty for a handful of SOPs. When a job needs more documents, see T04-L03.
How it reads its files	The agent receives relevant excerpts from its files, not necessarily every file in full.	One more reason to remove old versions: an excerpt from the old file can be the one it gets.
Sharing	Share with the whole workspace, or give usage and editing rights to specific groups or people.	This is how you give the team use rights and only you and your deputy edit rights.
Draft and publish	Changes are saved as a draft and don't reach users until you publish: Create for the first version, Update after that.	Colleagues never see a half-finished change.
Test sets	The Evals tab holds test sets of up to 50 cases. Each is graded by an AI judge (a second model comparing the answer with a reference answer) or by a Keyword check (Must mention / Must not mention, no model involved). A CSV import takes the columns `prompt`, `must_contain`, `must_not_contain` and `reference_answer`.	The worked example uses the first three columns. Add reference_answer only for cases graded by the AI judge.
Admin powers	Only workspace admins can reassign an agent to another person. An admin can Disable an agent; it stays unusable until a new version is published and approved.	Name your deputy now. If you leave, moving the agent needs an admin.
Claude alternative	On a Claude Team or Enterprise plan, a project can be shared with Can view (use it) or Can edit rights.	The same split of rights, but you run the test questions by hand.

Build a Shared Assistant Your Team Can Test and Take Over