2024 — presentDesign and implementation
AI Automation & Agent Layer
Assistants, RAG and n8n workflows wired into production systems
- answers grounded in tenant content, with citations
- RAG
- workflow orchestration across systems
- n8n + Make
- always-on assistant coverage
- 24/7
The problem
A general-purpose chatbot bolted onto a product is a demo. It does not know your data, cannot take action, and confidently invents answers the moment a question falls outside its training. The useful version has to be grounded in the organisation's own content and able to actually do something at the end of the conversation.
The approach
Retrieval-augmented generation over tenant-scoped content, agents with a narrow set of real tools rather than open-ended autonomy, and n8n / Make.com orchestrating the steps that touch external systems. Every answer cites what it retrieved, and every action a model can take is one a human could audit afterwards.
Architecture
- Content is chunked, embedded and stored per tenant, so retrieval can never cross an organisation boundary — the same isolation rule as the rest of the platform.
- A retrieval step with re-ranking runs before generation; the model answers from retrieved passages and says so, rather than from parametric memory.
- Agents expose a small, explicit tool surface (lookup, create ticket, schedule, notify) instead of arbitrary execution, so the blast radius of a bad decision is bounded.
- n8n and Make.com orchestrate cross-system workflows — webhooks and events in, CRM and messaging actions out — keeping integration glue out of the application services.
- Fine-tuning is reserved for tone and format consistency; facts stay in retrieval, where they can be corrected without retraining.
Retrieval first, fine-tuning last
Fine-tuning is the answer people reach for and rarely the one they need. It teaches a model how to sound, not what is true, and every fact baked into weights is a fact you cannot correct without retraining. Facts belong in a retrieval index where a content update fixes the answer immediately. I fine-tune for format and tone, and retrieve for everything that can change.
The retrieval quality is the product
Most 'the AI is hallucinating' reports are retrieval failures wearing a costume — the model answered honestly from passages that did not contain the answer. Chunk boundaries, embedding choice and re-ranking move accuracy far more than prompt wording does. Measuring retrieval separately from generation is what makes the system debuggable at all.
Give agents a small door, not a big one
An agent with open-ended execution is impressive in a demo and unbounded in production. A narrow, explicit tool surface means every action is one you can enumerate, permission and audit. It also makes failure legible: when something goes wrong you can see which tool was called with what, instead of reconstructing intent from a transcript.
Where n8n and Make.com earn their place
Integration glue rots faster than application code — the CRM changes a field, a webhook payload gains a key. Keeping that layer in n8n or Make.com rather than in service code means it can be changed by whoever owns the process, and a broken integration is a failed workflow run rather than a failed deploy. The rule I apply: application services own decisions, automation platforms own plumbing.