Give the agent an authoritative book on the subject as a wiki in the repo — indexed and cross-linked, not a one-off file drop into the chat. Then even a short prompt designs in the source’s terms: queues, delivery guarantees, idempotency, fault tolerance. Below: the book-as-context method, a shop→ERP walkthrough, and the method’s limits.
A familiar scene. Someone — a founder, a product lead, sometimes even an engineer outside their usual zone — opens Claude or Cursor and types something like: “move orders from the online shop into the ERP.” The ask sounds reasonable: orders appear on the site; accounting needs them. They skip the details not out of laziness, but because they do not know which details matter. “ERP is sometimes down,” “orders must not be lost,” “duplicates are bad,” “CRM should get them too” — all of that lives as common sense, not as requirements.
The agent answers with confidence. A minute later you have a design: dump orders to CSV on a cron, push the file over FTP, “something on the other side will pick it up.” The chat says “done.” From the outside it looks like a solution. Inside it is textbook minimum: a night batch, a share, manual cleanup when ERP did not answer, and a magical “just send again” when something vanishes.
From here the story splits.
Branch one: an engineer who has already built these paths is close enough to help. They look at FTP and see the bill — six hours of ERP downtime, stock drift, who owns redelivery, where the audit trail is. They go back into the chat and raise the brief: async, a queue, idempotency, a state journal, channel security. After a dozen clarifications the agent draws an adult design. The moral of this branch is familiar: “AI works if you already know how to ask.”
Branch two: that experience is not nearby. Or a seasoned colleague is around and smirks: “sure, chat-driven amateurs can ship a three-page site — never real architecture.” For them CSV-over-FTP is not a method bug; it is proof the model “can’t do architecture.” They are right about one thing: an empty prompt does not yield industrial grade. They are wrong about another: the model is not “dumb.”
The root is what the model was trained on. Open internet has orders of magnitude more tutorials about “export CSV and drop it on FTP” than production write-ups with a broker, an outbox, and retry semantics. The average temperature of the sample is textbooks and Stack Overflow, not a write-up from a real corporate integration. Without a domain base the agent does not know that the sane answer here is event-driven: an order is not “a file left”; it is an event that survives ERP downtime, does not duplicate on retry, and leaves a trail you can use in an incident review.
So the question is not whether AI “can do architecture.” The question is where it takes its bar from when you cannot state that bar yourself. If the domain is yours — you are the bar, and a long dialogue saves you. If it is not — you need an external carrier of expertise for the design phase. Not one more paragraph in the prompt (“make it reliable and production-ready”), but a substrate the agent must read as a tech lead’s handbook.
The method: book-as-context
Book-as-context means giving the agent an authoritative primary source (a book, a spec) as a structured context substrate: a wiki of concepts, cross-links, and traceability back to book chunks. It lives in the project; the agent walks it like a tech lead’s handbook — without hoping a single system-prompt line or raw PDF search will hold the architectural bar.
It is a concrete case of what people now call context engineering: the model works from a corpus assembled for the task, not from “whatever it remembers.” Nearby names in the community are other packagings of the same idea. LLM Wiki (Karpathy) — compile sources into linked markdown pages instead of pulling raw chunks from RAG on every ask. Book-to-skill (and “turn a book into a Claude skill”) — compress a book into a Claude Code / Copilot skill: SKILL.md, chapters, checklists the agent can load on demand. Delivery differs: a skill lives in the assistant’s skills folder; book-as-context puts the wiki in the project repo, so plans, specs, and code share one substrate. The point is the same — the book becomes working context, not a one-shot chat summary.
For distributed systems, high load, and eventing I used Tanenbaum’s Distributed Systems: Principles and Paradigms. In that zone it plays the role Kotler plays for marketers: hard engineering, not a blog paraphrase.
The cutting pipeline is obsidian-llm-wiki (olw, a fork in the LLM Wiki vein): a fast model for ingest (concepts from a chunk), a heavy model for compile (concept pages). On the Tanenbaum run: 30 source chunks → 116 concept pages. A full run is about $1.5 via OpenRouter. “Run once and ship” does not work: three runs produced 16 + 14 + 23 notes — chunk and model parameters need iteration.
The wiki sits in the repository (or a symlink). The agent does not load the whole book into the window: it walks the index and pulls the nodes it needs — via Cursor’s built-in indexing or a hybrid-search MCP. From there, plans, API contracts, infrastructure, and vibe-coding lean on the book’s concepts and methods. The bar holds from a single prompt: you do not have to append “add eventing, async, contracts, and fifty more requirements” every time.
One prompt, two worlds
Same class of problem. Two outcomes.
Without a substrate:
“Move orders from the online shop into the ERP”
→ CSV, cron, FTP, “done.”
With a Tanenbaum wiki — a real brief: 1C-Bitrix → ERP Galaktika → CRM Creatio. The agent does not rush straight into writing code, and it does not stop at a list of smart words. It walks the book’s concept graph first — from a business risk to the author’s term, from the term to a pattern:
“ERP may be down for hours; orders must not be lost”
→ message-oriented middleware:
persistent communication — the queue keeps the message until delivery
vs transient — the receiver must accept now
→ message queue systems — guarantees, journal, balancing
→ AMQP: unsettled → settled → forgotten
→ two-phase commit — when two databases must update atomicallyThose formulations do not stop as a smart paragraph in the thread. They get worked through on two layers. In the brief — spec sections, SLOs, transport priority, partial-success rules, a “wiki principle → section number” map. In the implementation — the same decisions become concrete mechanisms: a transactional outbox next to the order, a persistent broker, ERP/CRM adapters, idempotency keys on retries, a DLQ, an end-to-end state journal. Without a wiki the agent says “queue” and draws FTP; with a wiki the book’s queue has to survive into the design and into the code.
| Question | Without wiki | With wiki |
|---|---|---|
| Sync model | REST “sent — done” | DB outbox → broker → adapters |
| ERP offline | “resend tomorrow by hand” | queue buffers; shop keeps working |
| Loss / duplicate | “just send again” | idempotency key, at-least-once, DLQ |
| Path to ERP | FTP as the main path | bus/queue → REST/SOAP → file as fallback only |
| ERP + CRM | best effort | state journal, partial success, eventual consistency |
Spec excerpt: outbox, broker, adapters
Event source — Bitrix after order commit. The event is written first into the same database as the order (transactional outbox: record the fact, then promise delivery), mapped to a canonical model, and lands in a persistent broker. Adapters deliver asynchronously to ERP and CRM; end-to-end state lives in an integration journal. Retries use idempotency (a retry must not create a second order), backoff, and a DLQ (dead-letter queue for poisoned messages); per-order change order follows causal ordering.
[Shop 1C-Bitrix] --(Outbox)--> [Integration service]
|
canonicalize, validate, enrich master data
|
[Broker (persistent queues)]
/
[ERP Galaktika adapter] [CRM Creatio adapter]
/
`--> [State journal] <--'Transport priority to ERP: (1) corporate bus / queue manager, (2) HTTPS REST or SOAP, (3) file exchange — emergency or batch only.
And it is not only boxes on a diagram. In the same pass the agent pulled non-functionals using the book’s criteria:
| Metric | In the spec |
|---|---|
| RPO (how much data you may lose) for broker/outbox events | 0 — loss not allowed |
| RTO (how fast processing must come back) | ≤ 1 h normal, ≤ 4 h degraded |
| End-to-end ERP + CRM | P95 ≤ 5 min, P99 ≤ 15 min |
| Integration availability | ≥ 99.9% / month |
Partial ERP + CRM success is handled as eventual consistency without automatic 2PC: a successful write to a target is not auto-rolled back; if ERP accepted and CRM is down — retry CRM with the same idempotency key; if CRM exhausts retries — partial success, DLQ, alert. While ERP is down — do not call CRM.
Channel security is not “later”: TLS 1.2+, mTLS between components, shop webhooks with HMAC/JWS and replay protection, rate limits, queue overflow → DLQ.
The spec appendix has an explicit wiki → document section map: guaranteed delivery and persistence → SLO and topology; failure models → resilience; retry/idempotency → retry semantics; fallacies of distributed computing (“the network is reliable”, “latency is zero”) — listed as forbidden assumptions. The brief-writer may not have held that expertise in the moment. The primary source carried it.
“I don’t know the domain” does not mean “I don’t review the result”
Book-as-context does not turn you into Tanenbaum. It stops the agent from offering textbook minimums while you are still learning to write production-grade requirements.
You still have to go through what the agent produced — the way you read a strong architect’s brief: argue decisions, cut scope, accept trade-offs. The starting point changes. Without a wiki you argue with FTP. With a wiki you argue outbox vs 2PC, RPO and DLQ. That is a different conversation, even if yesterday you could not tell persistent communication from “drop a file on a share.”
Second skill, or the substrate softens: query the wiki in the author’s terms, not the task’s slang.
| Weak query | Strong query |
|---|---|
| “find something about Kafka” | reliable multicast + FIFO ordering |
| “how to sync orders” | persistent vs transient communication |
| “delivery guarantees” | AMQP: unsettled → settled → forgotten |
Wiki + retrieval without that layer is blind RAG: chunks are fine, hits miss. More on search in the hybrid-search howto.
How to build it locally
- Pick the book for the phase. Integration architecture — Tanenbaum (or your domain’s equivalent). Implementation — Clean Code. Review — Fowler. QA — a domain QA text. A weak source multiplies weakness into every agent answer.
- Cut into a wiki.
olw init→ chunks inraw/→olw run. Output: sources + concept pages with wikilinks and chunk traceability. - Drop it into the project. Wiki directory in the repo or a symlink. The agent must see the index.
- Query in the author’s terms. Business need → pattern from the book → implementation (Kafka or Rabbit is already a local tool choice).
- Verify drafts before you cite them. olw may mark
confidence: 0.35andsingle-source— re-check before you take a wording into an architecture review.
Vault anatomy and run parameters are in the howto: Book-as-context.
Limits of the method
- Parameters decide wiki quality. Early runs often produce fragments or walls of text — tune chunks, models, and run count until the pages stop falling apart.
- Coverage is partial. One run had 30 chunks and 116 concepts; a question outside that grid sends the agent back to the internet’s average temperature.
- A weak primary source multiplies weakness. A blogger compilation without failure models yields the same “average” architecture, only more confidently.
- Task-language queries miss. While the agent searches “about Kafka” instead of delivery ordering and retry semantics, it pulls tutorials again.
- The substrate does not remove ownership. Drafts get more adult, but shipping to production is still your call: scope, money, risk, stakeholder politics.
Who it is for
Founders, product and delivery leads who already see that “build me a system” fails, and engineers who want to type less while landing closer to industrial designs. The method travels: a wiki is text; copy or symlink it across projects. The bottleneck is picking the primary source; “you’re smart, invent it” does not stand in for one.
Bottom line
AI “can’t do architecture” while you feed it an empty prompt and wait for a miracle from the internet’s average. Put a book underneath — and the argument moves to outbox, RPO, and DLQ.
Some programmers leave this alone on purpose: they fear for their jobs. Call it gatekeeper syndrome — the value feels like keeping the wrong people out of architecture, not like making the system better. It is easier to keep saying “AI can’t do architecture” than to admit that book-as-context, LLM Wiki, book-to-skill, and nearby mechanisms already raise the bar on both the brief and the build. People who actually want an industrial system pick up those tools. People who guard the pass to “the hard stuff” leave the agent on CSV and FTP — and call that proof.
Repo: github.com/dobryakov/obsidian-llm-wiki-local
Howto: dobryakov.net/howto/book-as-context.html
Retrieval layer: dobryakov.net/howto/hybrid-search.html
Related: skill onboarding for assistant behavior packs, and agent security when a system prompt is not a control.