AI Solutions

We do not train models from scratch; instead we place existing language models, or LLMs, inside the product you already run and the process your team already follows. We do it on two conditions: the result has to be measurable, and it has to be reversible. Measurable means accuracy is tracked as a number on a golden set. Reversible means that if the LLM layer is switched off, the process keeps working the way it did before. Building a demo is easy, because it only has to work once, for one scenario. The hard part is turning that demo into a system that runs every day, whose cost is known and whose errors are counted, and Detartech's AI work is that second part.

The scope of our AI solutions service

When we say AI solutions we mean the application layer. We are not a model lab: we do not train foundation models, we do not research new architectures, and we are not chasing benchmark tables. Our job is to build the layer around an existing model that makes it useful. That layer is retrieval (making sure the model sees the right data), verification (checking the output before anyone accepts it), workflow (which screen the output lands on, and after whose approval) and observability (what it spent, how long it took, how often it was wrong). A demo has none of these layers, which is why it comes together in days. A production system takes time because of them. There is also work we do not take on: projects with no verifiable definition of success, requests of the "let us put some AI in and see what happens" kind, and critical decisions whose output nobody will ever check.

Our service lines

The six headings below cover everything that comes up in an AI project. The first five are where a language model earns its place: knowledge retrieval, document processing, agent workflows, features inside your product, and opening your site to agents. The sixth is the opposite, where a language model costs more and adds nothing, and we say so upfront. Most projects start with one heading and add a second over time.

RAG and enterprise knowledge retrieval

We build systems that answer questions over your own documents, records and knowledge base. The work does not end with pasting a document into the model: we split the content at meaningful boundaries, turn the pieces into embedding vectors, then rerank the candidates so the model only sees the ones that are genuinely relevant. Retrieval quality gets measured on its own, because if the right passage never reaches the top of the list, the answer comes out wrong no matter how good the model is. Every answer shows which document and which section it came from. Source attribution is not an optional feature here; it is the default. An answer with no visible source cannot be used in a business process even when it is correct, because nobody can check it.

Document understanding and automation

We turn raw documents into structured data. The input can be a PDF, a scanned form, an email attachment or free text; the output is a record that matches your schema, filled in field by field. The same line also handles classification (what type of document, which department owns it), summarization and field-level comparison. The last step is the one that matters: the output is never written straight into your system. The model produces a confidence score and a source location for each field, and any record that falls below the threshold goes to a person for approval. That way the error rate does not climb out of control as automation goes up. Every approved record also becomes data for measuring accuracy.

Agent-based workflows

For work that takes more than a single question-and-answer turn, we build an agent. The model invokes the tools you have defined through tool calling: search, a database query, an API call, writing a file. The workflow moves through loops and graph structures, and the state of every step is stored. What happens on failure is written down in advance: how many retries, how long to back off, which errors get handed to a person. Every run leaves a step-by-step audit trail: which tool was called with which input, what came back, and at which step the decision was made. An agent with no audit trail gets switched off the first time it does something wrong.

LLM features inside your product

We add model-driven features to a product that is already in use: filtering in natural language, semantic search, suggestions based on user context, draft text generation, a short summary of a long record. We do not rewrite the interface to make room for them. The feature sits inside the existing screen, the classic path stays where it is, and the user can go back to the old flow whenever they want. If response latency goes past what a user will wait for, the feature is either streamed or moved to the background. When the model is unavailable the product keeps working; the LLM feature is built as a layer you can switch off, not as a dependency.

An agent-readable web surface: WebMCP and llms.txt

Agents now browse websites the way people do. Opening a site to an agent does not mean making it easier to scrape; it means handing the agent tools it can call directly. With WebMCP, an agent in the browser calls the tools the site itself defines. llms.txt tells a model which sources to read. An RFC 9727 API catalog announces to machines which APIs exist. Structured data leaves no ambiguity about what a page means. The result is that an agent acting on a user's behalf works against a defined interface instead of guessing. We implemented all of this on our own site, because we do not recommend something we have not run ourselves. Visibility inside AI answer engines is a separate subject, covered on our GEO service page.

Where classical machine learning is still the right answer

Not every problem needs a language model. When the job is predicting a number, classical methods are both cheaper and more accurate: demand and inventory forecasting, sales projection, churn scoring, anomaly detection in transaction records, visual defect classification on a production line. Here the input is already a structured table, and the model has to answer in milliseconds rather than seconds. Putting an LLM there raises token cost and latency for nothing in return. At the start of a project we separate which problem belongs to which method, and if we can solve something without an LLM, saying so is part of the job.

How we work

We move in three stages: proof of concept, pilot, production. In the PoC we build one real scenario on your own data and hand the result back with a measurement table; the goal is not an impressive show but a decision about whether the work is feasible. A PoC typically runs two to four weeks. In the pilot the system opens to a limited group of users, real errors are collected, and the flow is corrected against them. Production brings in monitoring, cost tracking, release management and handover documentation. We work in two-week cycles, and each cycle ends with a running version and its measurement. If you decide at the end of a stage not to continue, you keep working code, a data pipeline and the measurements.

How we measure accuracy

Whether an AI system works is settled by measurement, not by impression. We start by building a golden set: the real questions your team asks day to day, together with the answers you accept as correct. That set runs automatically through what we call an eval harness, a test setup that reruns every question on every change, so the result is measured again when a prompt changes, a model version is updated, or a retrieval setting is adjusted. When the score drops, you can see exactly which questions broke, which is how regressions stay traceable. We share the measurement results with you as a report. On critical flows a human stays in the chain: the model proposes, an authorized person accepts. "It seems to be working" is an observation. "We measured this score on this set" is data you can decide on.

Cost, latency, and model independence

What an AI feature costs to run matters more than what it costs to build, because every request spends money. We start a project by setting a token budget per request and a target latency. Repeated requests and fixed blocks of context are cached, steps that do not need long context are routed to a smaller and cheaper model, and output length is capped. The model call is not buried in the code; behind it sits a provider-independent abstraction, so when a provider raises its price or a better model arrives, the switch happens without rewriting your prompts and workflow. Where the data must not leave your premises, we run an open-weight model on your own infrastructure.

Security and data boundaries

The first document we write on an AI project is the data boundary document: which fields go to the model, and which never do. Identity numbers, contact details and payment data are either masked before the prompt or never carried at all; the model can do most of the work without them. Under KVKK and GDPR, the purpose of processing, the retention period and the legal basis are defined in writing. When we choose a provider, data residency and the guarantee that your data is not used for training are fixed by contract; where necessary we run the model on your own infrastructure. Every request and every output is written to an audit trail, so it can later be shown when a result was produced, from which input, and with which model version.

Where these are already running

The work below is either live or completed. Each one has its own page; follow the heading to read the project in full.

• detartech.com: WebMCP tools, llms.txt, an RFC 9727 API catalog and ai/service.json are live on our own site. The site is open in a way that lets an agent call defined tools instead of scraping the page. We run this surface ourselves before we recommend it.
• SanalRandevu: llms.txt, robots.txt rules written explicitly for 18 AI crawlers, Organization, WebSite and HowTo structured data, and fast indexing through IndexNow are in place.
• Lextum AI: the first-pass analysis of contracts running to hundreds of pages was automated; risk and compliance points were extracted, and the lawyer's time went to the clauses that mattered.
• World Summer Schools: raw program data was structured with a language model, summaries and category suggestions were generated, and content went live after human approval.
• bebekistiyorum.com: a content archive of more than 1200 URLs in 4 languages was made visible both in classic search results and in AI answers.