Home/Services

Four areas, one responsibility boundary

Each area is described the same way: what the work includes, what’s needed from you, what you get and where the boundary lies. In one system the areas combine: the agent relies on retrieval, runs on self-hosted inference and is measured with evals.

01 / orchestrate

Agent systems

An agent with limited tools, permissions and approval points, working inside the client’s systems.

What’s included

  • orchestration on the Protocore runtime: a reason–act loop, state between steps, recovery after failure
  • tool contracts: what can be called and with which permissions
  • human approval for risky actions
  • tool isolation, input and output validation, a log of every action

What’s needed from you

a description of the processes, access to the systems the agent works with, and a person responsible for the rules

Result

an agent with documented contracts, an action log, approval points and acceptance scenarios

Responsibility boundary

agent behaviour in the documented scenarios — Anchor Inference; business rules and access rights — the client

02 / retrieve

RAG and semantic search

Search over the client’s documents with measured quality: hybrid search and reranking select the fragments that answer the question.

What’s included

  • corpus preparation: text documents (PDF, DOCX, HTML, Markdown); scans and complex layouts get a separate OCR estimate
  • embeddings and index inside the perimeter; BM25 + kNN merged via RRF
  • reranking and noise filtering
  • retrieval quality evaluation on a regression set

What’s needed from you

a document corpus and a few dozen questions with expected answers; an expert who can say which answer is right

Result

a search pipeline with measured quality, a regression set and a description of how to update the corpus

Responsibility boundary

quality is measured on an agreed set — jointly; data and index stay with the client

03 / serve

Self-hosted inference

Open models on the client’s hardware via vLLM and Kubernetes; where needed, a hybrid with external APIs under agreed rules.

What’s included

  • vLLM in Kubernetes or on dedicated servers
  • choosing open models for the task and hardware
  • performance and cost: batching, quantization, context size
  • monitoring, alerts and an operations document

What’s needed from you

access to a cluster or GPU servers, security and network requirements, expected load

Result

a working inference service with monitoring, an operations document and performance measurements

Responsibility boundary

setup and handover — Anchor Inference; hardware, network and access — the client

04 / verify

Evals and observability

Measurement that shows whether things got better after a change of model, prompt or index.

What’s included

  • regression sets on the client’s data
  • LLM-as-a-judge with human spot checks
  • quality metrics and a dashboard for the team
  • in production: errors, latency, quality gate trigger rate; runs on every change

What’s needed from you

access to system logs, a domain expert’s participation in labelling, criteria for a good answer

Result

a quality dashboard, regression runs on every change, reports and an improvement plan

Responsibility boundary

measurement — Anchor Inference; the rollout decision — the client’s team

AI is part of the work openly: it is what we build and a development tool, and an engineer reviews the results. More in the section “Use of artificial intelligence”.

Stack: Python, asyncio, FastAPI, PostgreSQL, Elasticsearch/OpenSearch, vLLM, Kubernetes, Helm. Cost is estimated after task analysis (stage 1): you get a written description, architecture and a timeline estimate.

The system doesn’t end at the model’s answer

Four stages. Each has a written deliverable and an acceptance criterion; the work continues after the model’s first answer.

Task analysisweek 1

We fix what to measure and how

Data, perimeter constraints, access requirements and quality criteria. Without them there is no way to tell whether things improved.

output: task description, architecture, estimate; written acceptance
Prototype with metricsmeasurable

A first version on your data

Retrieval and prompt variants are compared on a regression set, not on gut feeling.

output: prototype and a metrics table on an agreed set
Deployment inside the perimeteron-prem or cloud

vLLM and Kubernetes in your infrastructure

Integrations and telemetry per an agreed list; monitoring and an operations document.

output: the system in your cluster; scenario-based acceptance
Operation and evalsongoing

Production quality under observation

Regression checks on model or index changes, error and latency control, quality reports. The client’s team continues the work independently.

output: reports and an improvement plan; support scope per the contract

Deployment, support, handover

What happens after launch and how your team keeps working without ongoing dependence on the contractor.

infrastructure

The cluster, GPU nodes, network and access are maintained by the client’s team. System services, models and indexes — Anchor Inference within the scope of the contract; the boundaries are fixed in the operations document.

incidents

Response on business days within one business day; other arrangements per the contract. Incident analysis with logs and traces, a written account of the cause and the fix. 24/7 support is not promised by default.

handover

Code in the client’s repository, configuration and Helm charts, documentation on operation and model updates, team training: your team can continue the work independently.