Start with the problem, build something useful and keep it working. Choose a service below to see what it means for your business.
A CLEAR PATH THROUGH OUR SERVICES
Plan. Build. Keep it working.
Three groups, nine services. Choose the help you need; you do not have to start at the beginning.
01Plan & prepare
02Build & connect
03Deploy & improve
Plan & prepare / SERVICE
AI planning & advice
Work out where AI could help, whether it is the right approach and what a sensible first test would look like.
AN EVERYDAY EXAMPLE
A team spends hours preparing a weekly report. We review the steps and agree which part is worth testing first.
Scope & technical details+
Discovery & architecture
Turn an operational problem into a realistic engineering brief. We map how the work happens, what a useful result looks like, and whether AI is the right tool.
Business process discovery and workflow analysis
Data readiness assessment and AI feasibility studies
Build-versus-buy and cloud-versus-on-premise assessment
Proof-of-concept development
Architecture, deployment planning and ROI evaluation
Current scope: Engineering approach. Availability is assessed for your project.
Bring scattered or inconsistent business information into a dependable form before building an AI tool.
AN EVERYDAY EXAMPLE
Customer names and product codes differ across spreadsheets. We plan a repeatable way to clean and combine the records.
Scope & technical details+
Data engineering & preparation
Reliable AI begins with reliable data. Missing records, inconsistent labels and stale sources become unreliable answers. We make data fit for its intended task before choosing a model.
Data collection, ingestion and ETL/ELT pipelines
Cleaning, normalization and dataset validation
Annotation and labelling
Structured and unstructured processing, including document parsing
Data quality monitoring
Synthetic data generation where appropriate
Training, validation and test dataset preparation
Current scope: Project-backed data workflows. Availability is assessed for your project.
Compare existing AI models on your actual task, then assess whether any extra customization is worth the cost.
AN EVERYDAY EXAMPLE
A document tool needs to recognize your industry’s terms. We compare suitable models before deciding whether extra training is needed.
Scope & technical details+
Model selection & customization
Compare commercial APIs, open-weight models and conventional ML against your own examples. Customization is justified by measured need, data rights and the cost of operating it.
Open-weight and commercial API model evaluation
Task-specific benchmarking and domain adaptation
Supervised fine-tuning and parameter-efficient fine-tuning
LoRA and QLoRA
Task-specific and predictive ML models
Quantization and model distillation where appropriate
Current scope: Selection demonstrated; training assessed per project. Availability is assessed for your project.
Help people find answers in approved company documents, with sources they can check and access rules that match their role.
AN EVERYDAY EXAMPLE
A new employee asks how a return should be handled. The tool finds the relevant company policy and points to the source.
Scope & technical details+
RAG & knowledge systems
Connect a model to the information your people are allowed to use. Retrieval supplies relevant source material at question time; it does not retrain the foundation model.
Document ingestion and embedding pipelines
Vector search, hybrid retrieval and reranking
Knowledge-base synchronization and document versioning
Source citations and access-controlled retrieval
Retrieval-quality evaluation and hallucination reduction
Current scope: Document search demonstrated; enterprise controls scoped. Availability is assessed for your project.
Connect AI to your existing software so it can help with a defined task. Sensitive changes need checks and the right approval.
AN EVERYDAY EXAMPLE
Ask about available stock inside your business software, then prepare an order draft for someone to review and save.
Scope & technical details+
Agents & business integration
Embed assistance into your ERP, CRM or application through explicit interfaces. Models can propose a next step; code validates it and the appropriate person or policy authorizes sensitive actions.
ERP, CRM and API integration
API-based tool calling and structured tool contracts
Multi-step orchestration and governed agents
Human approvals and read-only business assistants
Transaction-safe automation and role-based authorization
Audit logging, idempotency and retry handling
Current scope: Read/propose integration demonstrated. Availability is assessed for your project.
Use past business records to explore trends, spot unusual changes and assess whether forecasting could support better planning.
AN EVERYDAY EXAMPLE
A shop wants to plan stock for next month. We first check whether its sales records can support a useful forecast.
Scope & technical details+
Predictive analytics & ML
Not every business problem needs a language model. Statistical models and conventional machine learning estimate quantities, classify outcomes and detect unusual behavior, rather than generate a conversation.
Demand and sales forecasting
Inventory optimization and customer segmentation
Anomaly detection and quality prediction
Production yield analysis and predictive maintenance
Financial forecasting and operational risk analysis
Current scope: Analytics demonstrated; predictive models assessed. Availability is assessed for your project.
Assess whether an AI tool can run on your own systems or private infrastructure, with clear rules for how information is handled.
AN EVERYDAY EXAMPLE
A factory wants help finding internal instructions. We assess local hosting, hardware and access controls before choosing a setup.
Scope & technical details+
Private AI & on-premise inference
Assess local, private-cloud and hybrid architectures around your data, hardware and operational constraints. Local hosting changes who operates the model; privacy still depends on the complete deployment.
Locally hosted language models and private inference servers
On-premise assistants and hybrid inference
GPU/CPU assessment and quantized model deployment
Private document retrieval
Model serving and API integration
Infrastructure monitoring, data isolation and access controls
Current scope: Local architecture demonstrated. Availability is assessed for your project.
Check whether the tool gives useful answers, respects permissions and handles difficult situations before changes are released.
AN EVERYDAY EXAMPLE
An assistant must answer staff questions without revealing restricted records. We test both the answers and the access boundaries.
Scope & technical details+
Evaluation, safety & governance
Define what the system must get right and how it must fail. Evaluation results guide reviewed changes; they do not automatically update production models.
Model and retrieval evaluation
LLM-as-judge evaluation calibrated against human review
Golden datasets and regression testing
Prompt injection and tool authorization testing
Multi-tenant isolation tests and audit trails
Model/prompt versioning and cost/latency monitoring
Incident investigation and feedback-driven improvement
Current scope: Evaluation and governance demonstrated. Availability is assessed for your project.
Put an agreed solution into use, monitor how it runs and define who handles updates, failures and ongoing costs.
AN EVERYDAY EXAMPLE
An internal assistant is ready for a limited release. We agree hosting, monitoring, support responsibilities and a way to recover if something fails.
Scope & technical details+
Deployment & managed operations
Plan the release and the work after it: monitoring, recovery, upgrades and cost. The operating model and support responsibilities are agreed for each engagement.
Inference APIs and containerized deployment
Cloud/on-premise deployment and model serving
Autoscaling and request batching
Streaming, caching and rate limiting
Observability and usage analytics
Model lifecycle management
Performance and cost optimization
Current scope: Application deployment demonstrated; scale scoped. Availability is assessed for your project.
Architecture, model methods, hosting and governance.
+
THE AI TECHNOLOGY STACK
Know what’s underneath.
Select a layer to see what it does, who supplies it and where Kapkoti’s engineering fits.
APPLICATIONFOUNDATION
Your business + Kapkoti
Business applications
ERP, CRM, manufacturing dashboards, knowledge tools and domain-specific workflows. We connect assistance to the places your team already works.
IN PRACTICE
A question about stock, a retrieved SOP, or a draft ready for a person to review.
Shared responsibilities
Evaluation & governance
Acceptance tests, authorization, data isolation, versioning, audit records and incident handling. These controls reach across the stack, with responsibilities agreed between you, us and each provider.
IN PRACTICE
A model suggestion cannot grant itself access or authorize a transaction.
Kapkoti designs + integrates
Retrieval, orchestration & tools
Approved knowledge retrieval, workflow steps, typed tool contracts, API connections and human approvals built around the actual task.
IN PRACTICE
Retrieve an approved policy, check access, call a read-only business function and cite the source.
Provider-hosted or customer-hosted
Inference & model serving
The running service that turns model inputs into outputs. We integrate hosted APIs or configure a customer-hosted serving path, with capacity and operating responsibilities assessed.
IN PRACTICE
A commercial model API, an Ollama service or a suitable private inference endpoint.
Kapkoti engineers
Data engineering & customization
Pipelines, cleaning, parsing, datasets, embeddings and task-specific adaptation. Fine-tuning is a separate, measured decision requiring appropriate data and rights.
IN PRACTICE
A validated dataset, a synchronized document index or an evaluated adaptation experiment.
External technology providers
Models & ML frameworks
Commercial and open-weight models, PyTorch, Hugging Face and scikit-learn are external technologies selected for the task. Their licenses and limitations still apply.
IN PRACTICE
We select and integrate existing models. We do not claim to train frontier foundation models.
Hardware + cloud providers
Compute hardware & cloud
CPU, GPU, memory, storage and networking. We assess capacity and deployment choices; suppliers manufacture and provide the infrastructure.
IN PRACTICE
Customer-owned hardware, private cloud or a suitable hosted inference provider.
Facilities + utility providers
Physical infrastructure & electricity
Power, cooling, connectivity and physical facilities support every AI system. These are supplied by the chosen facility or infrastructure provider.
IN PRACTICE
Ownership, physical access and business-continuity requirements belong in deployment planning.
Top to bottom: application to physical foundation. Evaluation, access and governance apply across the relevant layers.
DIFFERENT TECHNIQUES. DIFFERENT JOBS.
What changes? What stays in the model?
01 / INITIAL TRAINING
Pretraining
Creates a model’s initial learned capabilities from training data. Frontier foundation-model pretraining is not our positioning; we primarily work with existing models and frameworks.
02 / WEIGHT ADAPTATION
Fine-tuning
Updates model weights using a training dataset for a task or domain. LoRA and QLoRA are parameter-efficient approaches. This needs suitable data, evaluation and an explicit training plan.
03 / RETRIEVED CONTEXT
RAG
Finds relevant information from approved sources and supplies it to the model at runtime. Adding documents to an index does not retrain the model. Source permissions and relevance still need testing.
04 / INSTRUCTIONS
Prompting
Gives a model instructions and examples at request time. It can guide behavior without updating weights. A prompt alone does not enforce authorization or transaction rules.
05 / EXPLICIT INTERFACES
Runtime tools
Let the application handle structured model requests through APIs or business functions. Code checks the arguments, caller permissions and action policy before anything sensitive happens.
06 / MEASURED PATTERNS
Conventional ML
Predicts, classifies or detects patterns using task-specific data. Statistical models and deterministic rules can solve a problem without a conversational interface.
DEPLOYMENT CHOICES
Where should it run?
Choose based on data sensitivity, task quality, hardware, budget and who will operate the system.
01
Hosted model API
A provider operates a proprietary or open model behind an external service. Requests leave your environment for processing under that provider’s applicable terms and configuration.
Assess retention, location, contractual requirements, availability, cost and the information sent.
02
Local or private inference
Run an appropriately licensed open-weight model on customer-controlled hardware or private infrastructure. You take responsibility for capacity, updates, network controls and operation.
Local inference can reduce external processing. It does not by itself prove privacy or compliance.
03
Hybrid architecture
Use local and external components for different tasks under explicit routing policies. Define what may leave the environment and what must stay within it.
Check embeddings, retrieval, telemetry, backups and every fallback path, as well as the main model.
EVALUATION, SECURITY & GOVERNANCE
Trust needs engineering evidence.
Evaluate the actual task.
Golden datasets, retrieval checks, regression tests and human review. A model judge is useful only with calibration and known limitations.
Enforce boundaries in code.
Test prompt injection, tool authorization and tenant isolation. Validate arguments and protect transactions with explicit approval and retry rules.
Observe and investigate.
Track costs, latency, outcomes and appropriate audit evidence. Investigate incidents and use feedback to prioritize improvements.
Release changes deliberately.
Version models, prompts and interfaces. Evaluation informs a reviewed release; it does not automatically modify production weights.
Controls and responsibilities are assessed for each deployment. No blanket certification, compliance or complete-privacy promise is made.
ENGINEERING EVIDENCE
Inside the project examples.
Architecture, implemented behavior, limits and future work.
+
Built example
Rigel ERP
01
Business question
02
AI gateway + permissions
03
Scoped PostgreSQL reads
04
Answer or reviewed draft
Simplified architecture from inspected code. This does not verify the current deployed version.
Implemented in the project
Supabase/PostgreSQL business integration and a commercial model API
Permission-filtered views and a read-only database role
Metric compilation, guarded SQL and grounded answers
Audit records, usage controls and an evaluation harness
Draft quotations and orders handed to ordinary forms for a person to save
Boundaries and current maturity
The assistant reads and proposes. A person saves a draft through the ERP’s normal validated workflow. The inspected implementation uses an existing commercial model through OpenRouter; no model fine-tuning was verified.
Implementation is evidenced in project code. The deployed assistant revision and production readiness have not been independently verified for this website. A broader typed tool registry and workflow orchestration remain roadmap items.
Future work
A fuller tool registry, workflow orchestration and additional domains are roadmap work, rather than claims of completed delivery.
These examples do not establish a customer deployment or production readiness.
Simplified architecture from inspected code. This does not verify the current deployed version.
Implemented in the project
Natural-language business queries with SQL validation paths
Factory dashboards, yield/waste analysis and operational alerts
Document ingestion and vector search
Query/audit records and evaluation tooling
An Ollama provider in the standalone implementation; a configurable OpenAI-compatible client in the active monorepo
Boundaries and current maturity
Deployment matters. The standalone implementation supports Ollama; the active monorepo defaults to an external OpenAI endpoint and can use a compatible endpoint. A local database alone does not make model processing private. Isolation, permissions and egress need deployment-specific checks.
Present this work as an engineering demonstrator. Documented hardening gaps and unverified live configurations prevent a blanket privacy, compliance or production-readiness claim. Alerts support operational review; they do not replace certified monitoring or sign-off.
Future work
Customer-specific schema mapping, access hardening and deployment validation are required before a production engagement. The historical-average waste estimator is not a trained forecasting model.
These examples do not establish a customer deployment or production readiness.
Simplified architecture from inspected code. This does not verify the current deployed version.
Implemented in the project
Survey authoring, publication and conversational conducting
Schema-constrained model outputs and engine-owned question state
Validated structured responses and persisted conversations
Results, checked summaries, CSV and print/save-as-PDF exports
Private workspace, invitation and demo access controls
Boundaries and current maturity
The application owns state and validates model output. Hosted OpenAI-compatible model APIs assist the workflow. This is not evidence of a survey-trained foundation model or general document-intelligence platform.
A pilot implementation with documented release requirements: production identity, restricted database access, funded provider configuration, cookie behavior, retention scheduling and tested backups still require deployment verification.
Future work
Automatic pass issuance, entitlement webhooks, cross-survey comparisons and action tracking are documented future work. No capacity or training-performance claim is made.
These examples do not establish a customer deployment or production readiness.
