Generative AI and custom AI assistants

Beyond a chatbot window

General-purpose chat tools are good at general questions. They do not know your price list, your SOPs, your product specifications, your past proposals or your customer history, and they should not be given that data without controls. Custom generative AI connects a large language model (LLM) to your own knowledge, safely, and wraps it in a workflow that does a specific job.

The jobs we build for most often:

• Internal knowledge assistants. Staff ask questions in plain language and get answers drawn from your manuals, policies, past tickets and specifications, with links to the source.
• Customer-facing assistants. Website and WhatsApp assistants that answer product, order and service questions, capture leads and hand over to a person when needed.
• Report and document generation. First drafts of inspection reports, proposals, quotations, discharge summaries, student report cards or monthly MIS commentary, generated from structured data and reviewed by a person.
• Content at scale. Product descriptions, catalogue copy and translations in your brand voice and in Indian languages.
• Agentic workflows. Assistants that do more than answer: look up an order, create a ticket, draft an email or update a record, within permissions you define.

How we keep answers grounded

The main risk with generative AI is a confident wrong answer, often called a hallucination. We reduce it by design rather than hoping the model behaves:

• Retrieval-augmented generation (RAG). Before answering, the system searches your approved documents and gives the model only the relevant passages. The model answers from those passages and cites them. Our glossary entry on RAG explains this in more detail.
• Scoped knowledge. Each assistant only sees the documents its users are allowed to see, so the sales assistant cannot quote HR policy and a customer cannot see internal pricing.
• Refusal when unsure. If the answer is not in the sources, the assistant says so and offers to connect a person, instead of guessing.
• Human review for outputs that matter. Generated reports and customer messages can require approval before they are sent.
• Evaluation sets. We build a list of real questions with known correct answers and test every change against it, so quality is measured rather than assumed.

Our build process

Discovery

We identify one high-value use case, the people who will use it, the documents and systems it needs, and how success will be measured: time saved per task, tickets deflected, or turnaround time on a report.

Prototype

We load a representative slice of your knowledge, build the assistant or generator, and test it with a small group of real users against an evaluation set. You see where it is strong and where it needs work.

Production

We deploy on Google Cloud with authentication, access control, logging and cost controls, and connect it to the channels your team uses: a web app, Google Workspace, Slack, WhatsApp or your own software.

Improvement

We review logs of unanswered or poorly rated questions, fill knowledge gaps, tune prompts and retrieval, and keep model versions up to date.

Choosing models and keeping costs predictable

We are model-agnostic. Depending on the task, budget and data-residency needs, we use leading hosted models (such as Google Gemini) or open models that can run in your own cloud project. We cache common answers, route simple questions to smaller, cheaper models, and set usage limits, so running costs stay predictable as adoption grows. If you are weighing a subscription tool against a custom build, read build vs buy AI for SMEs.

Examples from our own products

We use the same techniques in the products we ship. Kepton runs a language model entirely on an Android phone to draft replies in the user's own voice. Webonika for Schools generates quizzes, worksheets and report drafts from a teacher's own material. Webonika Fitness generates diet and workout plans from a member's body report.