You have watched a spec become running software. Now do the work that makes an agent good at your project: author the architectural artefacts it reads — the written-down rules, models, and decisions that describe how your system works. You will not run canned code in these exercises — you will write down how YOUR system thinks, the way a mature codebase writes down how it thinks. This course itself is one enormous worked example of that: every rule, model, and decision that keeps a large platform coherent is written down and indexed (turned into a form an agent can search) so an agent can retrieve it on demand.

This is a first taste of Module 3 — The Knowledge Base: an agent is only as sharp as the knowledge base you hand it.

How each exercise works

1. Read the brief — one artefact, one page.
2. Study a mature codebase for ideas — open the linked reference page and study how a mature codebase says the same thing. Steal the shape, not the words.
3. Create it in your own home — write the artefact as a page in your space, e.g. {yourHome}/Rules. {yourHome} is your personal space on the mesh; swap in your own path.

Your copy of this page — with all four briefs — is installed with the course. Create your artefacts there — {yourHome}/Rules, {yourHome}/DataModel, {yourHome}/TestingStrategy, {yourHome}/Decisions/0001-<slug> — right alongside the briefs, and edit freely.

Exercise 1 — Write your project's lean rules

Every effective agent setup starts with a blunt rules page — the no-X / always-Y list an agent must obey. Not a style guide nobody reads: the five-to-ten invariants that, if broken, break your system. Name each rule, say why in one sentence, and show the one-line right-way and wrong-way.

• Browse for ideas: No Static State — a single rule ('any static mutable collection is forbidden'), its reason, the wrong way, the right way, and the build-time test that enforces it. Then Asynchronous Calls — how one hard rule ('nothing async, ever') is stated and defended without hedging.
• Create in your home: {yourHome}/Rules — an AGENTS.md-style page. Lead every rule with a verb — Never …, Always … — and give each a one-sentence reason plus a right/wrong pair. Blunt beats polite.

Exercise 2 — Document your data model

An agent that does not know your entities invents them. Write the core of your domain: the five-to-eight entities that matter, their key fields, and how they relate. A table or a small class diagram is plenty — the goal is a map, not a schema dump.

• Browse for ideas: Data Modeling Guide — how a model layers shape (records), behaviour (attributes), and lookup values, with a diagram of one entity referencing two others. Then Data Cubes — A Pension Fund Balance Sheet for a real domain modelled end-to-end.
• Create in your home: {yourHome}/DataModel — name each entity, its key fields, its owner, and the relationships between them. A mermaid classDiagram or a plain table both work.

Exercise 3 — Write your testing strategy

'How do we test this?' is a question you should answer once, on a page, not re-argue on every change someone proposes. Write what a test means here: what you test, what you never mock (never replace with a fake stand-in), how you wait for a result, and how the agent runs the whole set of tests.

• Browse for ideas: a mature codebase's testing guide — what to test, what never to mock (never swap a real component for a fake stand-in just to make a test easier), and why you wait on a condition instead of sleeping. Then Test State Isolation for the one discipline that keeps a suite from bleeding across cases.
• Create in your home: {yourHome}/TestingStrategy — your unit-vs-integration line, your never-mock list, your one anti-flake rule, and the exact command the agent runs.

Exercise 4 — Capture a design decision

The most valuable artefact is the cheapest to write: a short record of why you chose X. Six months on, nobody remembers the alternatives you rejected — so an agent re-proposes them. One record per decision stops that cold.

• Browse for ideas: Data Versioning Strategies — 'we delegate to each backend's native capability because a cross-cutting shim would cost more than it is worth': a decision with its alternative named out loud. Then Controlled I/O Pooling — a choice defended against the obvious-but-wrong option.
• Create in your home: {yourHome}/Decisions/0001-<slug> — four headings, one screen: Context (what forced the choice), Decision (we chose X), Because (the reason), Alternatives (Y, Z — and why not).

Ideas to steal

There is no answer key here — the answer key is a mature codebase's own written-down knowledge. A short shelf of pages worth reading purely as well-written architectural artefacts, then imitating:

• Actor Model Architecture — one big idea, explained from first principles.
• CQRS — Queries, Reads, Writes, Operations — a rule with the reasoning that earns it.
• Mesh Graph Architecture — a data model told as a story.
• Message-Based Communication — patterns named so you can point at them.
• Error Propagation & Wedges — a failure mode written down so it stops recurring.
• User Interface Architecture — the shape of a whole layer, on one page.

← Back to Module 1 · Next: Module 3 — The Knowledge Base →