The usual stack is honest about what it is: n8n or Langflow for the canvas, LlamaIndex or unstructured.io for the files, a frontier model for the hard parts. Then every company still rebuilds the same missing layer — routing, structured aggregation, verification, configuration, and a UI that is not a chat box.
A canvas is not a platform
Researcher/writer architectures are everywhere now, and they are a good default: one pass gathers, one pass writes. The problem is not the pattern. It is that a workflow canvas stops at "nodes that call models." Three extra nodes are what make the pattern survivable outside a demo.
- Automatic routing into a folder hierarchy. Files should land in a tree — supplier, matter, period — not in a linear run history. Routing is a product decision, not a prompt.
- An aggregator as its own node. Unstructured in, typed records out. Cleaning, classifying, and shaping data is a job. Burying it inside the researcher step is how you get confident nonsense.
- A reflection / verification step.A second pass that can refuse to ship: schema checks, deterministic rules, a critic agent, or a human. Without it, every downstream system inherits the model's worst day.
UX that is not another chat
If the interface is only a prompt, operators lose the two things they already know how to do: find a file, and move it. The workspace that actually gets used looks ordinary on purpose.
- Full-text search with a snippet. Postgres indexing, jump to the hit. Vector search is extra; keyword search is how people work at 4 p.m.
- Resizable panes, so a document, a chat, and a result can sit side by side and the user decides the split.
- Keyboard shortcuts to open those panes instead of hunting through menus.
- A drag-and-drop folder tree so hierarchy is something you fix with the mouse, not a migration ticket.
The useful trick: one app, one corpus, several islands. Attach a folder — or a whole branch — to a given agent or workflow. You keep an overview of everything, and you still isolate data so the invoice extractor never sees the deal room.
Config first. Then a chat that only edits config.
A large settings surface sounds unsexy. It is how you stop waiting on embeddings to find out a parser cannot read the diagram on page three. Open-source parsers differ on layout, vision, and length; you want to try them on a sample before a pipeline run.
- Start with a settings / parser test page. Same knobs you will need in production, minus the queue.
- Keep a schema and a config model — then do not make humans edit JSON to improve results. The prompts and skills that search, analyze, and format the writer output will move in production. That is normal.
- Give them a separate agent that does not run workflows. It helps rewrite instructions, skills, and index notes — the same job as keeping
AGENTS.md, skills, and a README in a software repo. CopilotKit plus AG-UI on Supabase can drive generative UI here; the integration has sharp edges, and the workarounds are fine.
When not to open a frontier chat
Chatting with the most expensive model is a product choice, not a default. Most of the useful work can start before anyone sits down.
- Event-driven, cheap, or batch.Small models in the background when latency is not the constraint. OpenAI's Batch API is roughly half the price with hours of delay — which is a gift if the draft should simply be ready when someone opens the screen.
- Strip the model on stable PDFs.When the document is text-heavy, the layout does not move, and the fields sit in the same place every time, a deterministic parse — OCR, templates, rules — beats an LLM. You are not asking the model to "understand" the page; you are reading coordinates.
- Keep calculations and app logic in ordinary code. Totals, VAT, matching, validation, routing — functional programming and plain algorithms are still more robust than a prompt. The model belongs where structure is fuzzy; the rest of the app should stay deterministic.
- Deep agents are for long-running work. Spawning sub-agents multiplies calls. A simple ReAct loop plus hybrid search, and a better model, is usually the more honest architecture.
Pilot shapes, not a pitch deck
These are engagements I would actually run — comparisons and pipelines, not claims about a model I already crowned.
- Classification and meeting noteson a small specialist model versus a frontier LLM, inside the same agent shell. The question is not "which is smarter" — it is whether the cheaper one holds on this taxonomy, these transcripts.
- User-defined PII / anonymization. Staff describe what must disappear; the pipeline extracts and masks it. Regex remains a backstop, not the product.
- Background drafts on small or batch models so analysis is waiting, instead of a chat that starts at zero.
- Web research, cost first.Frontier browsing is often the most expensive node in the graph. A thin ReAct agent with Tavily — or a search plus an open crawler on the URLs — is usually the experiment worth running before you pay for "the model that can browse."
None of that is a canvas you drag together once. It is a platform you configure, isolate, and fit into the automation the company already has — n8n included — with optional UI where operators need to see the work.
Get this fitted to your flow
I build this as a custom platform into the automation you already run — n8n or otherwise. Routing, aggregation, and verification as nodes; optional UI for search, folders, and a resizable workspace; a config surface for parsers, prompts, and skills.
Start a platform conversation →