The AI architecture sketch: one page that beats a 40-page design document

A workshop that ends with a list of ideas and no picture of how the first one works has produced a wish list. The architecture sketch is the one page that turns the top use case into something an engineer can estimate, a process owner can object to and a manager can fund, before anyone writes a design document.

What the sketch is, and what it is not

The sketch is a single page showing the components of the proposed automation and the arrows between them. Boxes for systems, arrows for data, a distinct mark for every place a human decides. It fits in a whiteboard photo and it is finished in the last hour of the workshop, while the people who know the process are still in the room.

It is not a technical specification. It does not name model versions, prompt wording, retry policies or database schemas. Those decisions are cheap to change later. The decisions on the sketch — what triggers the workflow, which system is the source of truth, where a person approves — are expensive to change once code exists.

The components that go on the page

Most automations Hilluter builds use the same seven building blocks. The sketch shows which ones this use case needs and, just as important, which ones it does not.

1. Triggers

What starts a run: an email arriving in a shared mailbox, a form submission, a row appearing in a table, a schedule, a webhook from another system. One trigger per sketch is the norm. Two is usually a sign that two workflows are being drawn as one.

2. Workflow steps

The orchestration, in our builds an n8n workflow: fetch the input, call the model, validate, write, notify. Each step is a box with a verb. The sketch shows the happy path and one failure path — where a run goes when a step fails.

3. Model calls

Every LLM call is its own box with what goes in and what must come out. "Classify intent, return one of six labels plus confidence" is a box. "Use AI" is not. If the sketch needs more than three model boxes, the use case is probably too wide for a first version.

4. Retrieval

If the model needs context it does not have — product manuals, past tickets, contract clauses — the sketch shows the source, the index (vector search over Postgres in most of our builds) and the refresh rule. What is indexed and how often it is rebuilt are business decisions, and the sketch is where they get made.

5. Systems of record

The CRM, ERP, ticketing system or database that the automation reads from and, sometimes, writes to. Each gets a box and a permission next to the arrow: read, write or propose. The data readiness check decides what is possible here; the sketch records the decision.

6. Human approval steps

Every point where a person sees the model's proposal and decides. Drawn as a distinct shape so nobody can miss them. The sketch also notes what the approver sees, because a gate with no evidence is a rubber stamp.

7. Guardrails

Marked on the arrows, not in a separate box: input validation at the trigger, schema validation after each model call, reconciliation against the system of record before any write, limits on the write itself. The guardrail layers are designed here, on the same page as the flow they protect.

What is deliberately left out

A good sketch is defined as much by its omissions. The things we refuse to draw at this stage:

• Model vendor and version. The box says "LLM: extract fields". Which model fills it is an evaluation result, not a workshop decision.
• Prompts. Their wording changes weekly during the build; the sketch fixes only the contract: inputs, outputs, labels.
• Hosting, scaling and cost projections. Volume is known from the scoring sheet, and that is enough to estimate.
• Every edge case. The sketch shows one failure path. The rest are the evaluation harness's job.
• Phase two. Anything that starts with "and later we could" goes in a margin note, not in a box.

A worked example: tenant requests at a property manager

A property management company with about 3,000 units receives maintenance and billing requests from tenants by email and through a web form. Requests are triaged by hand, and urgent ones (water, heating, lockouts) sometimes wait behind routine ones for hours. The sketch drawn at the end of the workshop, in text form:

Trigger: email to the requests mailbox (Microsoft 365) or web form
  -> n8n: fetch, strip signatures, attach tenant record from PM system (read)
  -> LLM 1: classify {maintenance, billing, contract, other} + urgency 1-3 + confidence
     [guardrail: schema check; confidence below 0.7 -> human queue]
  -> if maintenance: retrieval over building manuals + past tickets (vector search)
  -> LLM 2: draft reply + proposed work order (structured output)
     [guardrail: reply may not promise a date or a cost]
  -> Human: property manager approves reply and work order (sees email, draft, evidence)
  -> n8n: create ticket in PM system (write, tickets only), send reply
Failure path: any step error -> ticket with raw email, flagged "unprocessed"

Three things on that page took the most discussion: the property system is written to for tickets only, never for tenant data; every reply is approved by a person until measurement shows where that gate can be relaxed; and the urgency label is a proposal the manager can override, with overrides logged. None of those is a technical decision. All of them are on the sketch.

Why one page beats forty at this stage

A 40-page design document in week one is an exercise in false precision. The people who would have to read it will not, the decisions it fixes will be wrong in ways nobody can see yet, and it delays the moment when something runs. The sketch does the opposite: everyone in the room can find the box they own, object to it and have it changed in the same hour.

A sketch is good enough when it answers these questions without a second page:

• What starts a run, and how often.
• Which system is the source of truth for each fact the model touches.
• What each model call receives and what it must return.
• Where a person decides, and what they see when they do.
• What the automation may write, where, and with what limit.
• Where a failed run goes.
• What is explicitly out of scope for the first version.

The sketch is the last output of Hilluter's workshops and the first input to the 30/60/90-day roadmap; the day-30 milestone is usually "the sketch is running on real inputs". If you have a use case and want to see it drawn this way, describe the process and we will send back a first sketch and the questions it raises.