A reference architecture here means the lanes and components a real build runs through, what it costs, and what breaks if a piece goes missing, not a slide of boxes and arrows with nothing behind it.
Patterns and failure modes on this site are component-level: one decision, one thing that breaks. A reference architecture is the level above that: the whole system a buyer actually asks for, assembled from several of those components, with the cost shape and the security posture that only make sense once the pieces are together. Pick the one that matches what you would actually say out loud if someone asked what you need built.
Answer questions from your own documents, with a citation, instead of from whatever the model learned during training.
“We want a search box or chatbot that answers from our own docs and can show where the answer came from.”
Read the architecture →An agent that works a queue of cases end to end, inside a bounded loop with a human checkpoint on anything it cannot cleanly undo.
“We have a queue our team processes by hand, and we want an agent to work through it without babysitting every case.”
Read the architecture →Turn inbound documents into structured records, with a person reviewing only the cases the model is actually unsure about.
“We get PDFs, forms, or emails and someone manually keys the data into our system. Can this just get read automatically?”
Read the architecture →An assistant embedded in a product you already ship, scoped to that signed-in user's own data and permissions.
“Our users keep asking support the same questions they could answer themselves if the product could just tell them.”
Read the architecture →One call site in front of every model provider, so a price change or an outage is a config change, not a rewrite.
“We're calling one provider's SDK directly from a dozen places, and we want to be able to switch or split traffic without touching all of them.”
Read the architecture →A control plane for running many coding agents at once without them colliding on the same files or losing track of what any of it costs.
“We're running several coding agents already, and it's turning into a wall of terminal tabs with no idea what any of it actually costs.”
Read the architecture →Start from the sentence a stakeholder would actually say. "Answer questions from our own docs" is grounded answering. "We have a queue we process by hand" is the workflow runner. "Someone keys data in from documents all day" is extraction. "Users ask support what the product could tell them" is the copilot. "We're stuck on one model provider" is the gateway. "We're running agents and losing track of them" is the delivery fleet. A system that is genuinely two of these at once, a copilot that also extracts from an upload, is common; read both pages and combine the parts that actually apply.
Or skip the self-diagnosis: the Architecture Picker turns these same questions into a scored primary and a likely bolt-on, in about a minute.
What a reference architecture means on this site, and how to use one honestly.
A named system shape we have actually built more than once: the lanes and nodes it runs through, the components that would break something specific if removed, the build-versus-buy calls it forces, and what it costs to run. Not a diagram of a hypothetical, and not a product pitch.
Link to this answer: What exactly counts as "a reference architecture" here?Start from the sentence you would actually say out loud. "We want to answer questions from our own docs" is grounded answering. "We have a queue we process by hand" is the workflow runner. "Someone manually keys data from documents" is extraction. "Our users ask support what the product could tell them" is the copilot. "We're locked into one model provider" is the gateway. "We're running agents and losing track of them" is the delivery fleet. Most real projects are one of these plus a second one bolted on, not something entirely new.
Link to this answer: How do I pick which one applies to us?No, they sit one level above it. A pattern like bounded agent loop or typed tool contractA tool contract is the schema a tool exposes to a model. is a component-level decision; a reference architecture is the whole system those components assemble into, with the cost shape, the build-versus-buy calls, and the security posture that only make sense once you can see the whole thing.
Link to this answer: Do these replace the patterns library?Because we would be citing them anyway as examples of the pattern, and pretending otherwise would be strange. CostMon and CodeHerder are our own answers to the cost-telemetry and fleet-control problems named in the model gateway and delivery fleet architectures, offered as one option among several, not the only shape that works.
Link to this answer: Why do two of these mention your own products?Most production systems are. A copilot that also extracts data from an uploaded document is genuinely both. Read both pages, take the components and build-versus-buy calls from each that actually apply, and treat the "not for you if" sections as a filter on the parts that do not.
Link to this answer: What if our system is a mix of two of these?A Ship Audit checks which of these your actual system needs, and which parts of your build already have them, before you commit budget to the rest.
Source: https://customlabs.io/architectures/