Back to Services

Consulting

AI Assistants for Business Systems

Assistants for your team or your customers that know your domain, answer from your own documents and data, cite their sources and hand over to a person when they should.

AI assistants RAG MCP Laravel AI Evaluation

A useful assistant is not a model with a long system prompt. It is a small product: it knows what it is for, it answers from sources you control, it says when it doesn't know, and it hands over to a person at the right moment. Getting those four things right is most of the work.

I build assistants for internal teams, for customers, and inside products.

Kinds of assistants

  • Internal knowledge assistants. Onboarding, procedures, product details, "how do we handle X". Answers come from your own documentation, kept versioned in one place and served through MCP, so the same knowledge also reaches Claude, ChatGPT or Cursor when your team works there.
  • Customer-facing assistants. Support and pre-sales answers grounded in your documentation and catalog, with clear limits and a handover to a person when a question needs one.
  • In-product assistants. A natural-language way to use your own application: "show me last month's overdue invoices", "draft a reply to this request". They act through the application's own permissions, which is where an assistant meets the agent layer.
  • Developer and design assistants. Tools that bring a specialised dataset into AI-assisted work, like espectro.dev, which brings Sanzo Wada's color combinations into Claude and Cursor through MCP.

What makes them trustworthy

  • Sources, not memory. Answers come from your documents and data, with citations a reader can open.
  • Scope. The assistant knows its subject and declines the rest, instead of improvising.
  • Permissions. An internal assistant sees what the person asking may see, nothing more.
  • Handover. Clear rules for when a human takes over, with the conversation so far attached.
  • Measured quality. A set of real questions and expected answers, re-run whenever the prompts, model or content change.

How I build it

Knowledge is kept as code: Markdown in Git, edited through a simple interface by the people who own it, reviewed like any other change, and exposed to the assistant through MCP. Retrieval is designed for your content, with a knowledge graph where relationships matter. The assistant itself lives in your Laravel application or beside it, using Laravel AI or the provider SDK that fits, with conversations, feedback and costs logged.

What you get

  • A defined assistant: purpose, audience, sources, limits and handover rules.
  • The assistant in production, connected to your content and systems.
  • A content workflow so the people who own the knowledge can keep it current.
  • An evaluation set and the numbers from it.

When it fits

The same questions get asked every week, the answers already exist somewhere in your documents or your system, and finding them takes longer than it should.

Knowledge as Code: Connecting Business Knowledge to AI with Git and MCP Records answer WHAT and WHO. Knowledge answers WHY and HOW. Keep that knowledge in Git as one source of truth, edit it in a simple web editor, and serve it to every AI tool through MCP. AI 6 min Why RAG Is Not Only Retrieval-Augmentation-Generation RAG sounds like three steps, but production pipelines need classification, intent, graphs, reranking, summarization, and more. Here is how real systems differ from the tutorial version. AI 12 min Sanzo Wada's Colors in Your Code: How I Brought a 1930s Color Dictionary to AI and Web Development A story about aesthetic, a forgotten Japanese artist, and turning 348 curated palettes into an MCP server that actually helps me build better interfaces. Reflections 12 min