LLM & AI Engineering Foundations is Right.Link's service for teams that already have an AI feature in production, or are about to, and need to be able to trust it. We set up evaluations so you can tell whether a change made things better, guardrails so the feature fails safely, cost and latency controls so usage does not surprise you, and observability so you can see what the model did and why. It is built for engineering teams that shipped quickly and now need to run AI as a dependable part of the product.
Who is LLM and AI Engineering Foundations for?
It is for teams that have an AI feature live or close to launch and are discovering that "it worked in the demo" is not the same as "it works for everyone, every day, at a cost we can plan".
Typically that means an engineering lead or CTO with a product that calls a language model, a team that changes prompts by feel, and a growing list of questions nobody can answer with data.
If you have not built the AI feature yet, see AI Integration for Existing Products. If your app was built mostly with AI coding tools and is unstable, see Vibe Code Rescue. This service is about the AI behaviour itself.
How do I know my AI feature needs foundations?
Check how many of these are true today:
- You cannot tell whether last week's prompt change made the feature better or worse.
- The same question gets different answers, and nobody knows how often.
- Users report wrong answers and you cannot reproduce them.
- The model provider bill grows and nobody can say which feature causes it.
- Responses are slow at peak times, or time out.
- You have no record of which prompt and model version produced a given answer.
- You worry about prompt injection, personal data in prompts, or the model acting beyond what the user may do.
- A model upgrade or provider change feels risky because there is no way to compare.
One or two is normal for an early feature. Three or more means the feature has outgrown how it is being managed.
What are evals, and why do they come first?
An eval is a repeatable test for AI behaviour: a set of real inputs, a definition of a good result, and a score. Without evals, every change is a guess.
- Start from real cases. We build a test set from your real inputs, including the failures users reported, and label what a good answer looks like.
- Test the parts separately. Retrieval, extraction, classification and generation fail in different ways, so we measure them separately where we can.
- Automatic checks first. Format, required fields, allowed values, citations and similar rules can be checked by code.
- Model-based grading with care. When we use a model to grade answers, we compare its grades with human labels on a sample so we know how far to trust it.
- Run on every change. Prompt, model, retrieval settings and code changes are compared against the same set before release.
The result is that "is it better?" becomes a number you can look at.
What guardrails does an AI feature need?
Guardrails make the feature fail safely. Which ones you need depends on what the feature can see and do.
- Input checks: limits on size and content, and handling of untrusted text such as uploaded documents or web pages.
- Prompt injection defences: treating retrieved and user-supplied text as data, not instructions, and limiting what the model's output is allowed to trigger.
- Output validation: structured outputs checked against a schema, with retries and a clear failure path.
- Permissions: the model never gets data, tools or actions the user could not use directly.
- Personal and sensitive data: deciding what may be sent to a provider, redacting what must not be, and keeping it out of logs.
- Fallbacks and human review: low-confidence or high-impact cases go to a person or to a safe default.
No set of guardrails makes a model perfectly safe. We say what each one covers and what it does not.
How do you control cost and latency?
Both come from the same place: knowing what each request does.
- Usage tracking per feature: tokens, calls and cost by feature, customer and model, so you can see what drives the bill.
- Right-sized models: routing simpler tasks to smaller models and keeping larger ones for the hard cases, checked against the eval set so quality does not drop silently.
- Caching and reuse: avoiding repeated work where the same inputs recur.
- Prompt and context trimming: sending only what the task needs.
- Streaming, timeouts and limits: the interface stays responsive, and a slow provider does not hang the product.
- Budgets and alerts: hard caps and warnings, so a bug or abuse cannot produce a surprise invoice.
We make changes one at a time and re-run the evals after each, so savings do not cost quality.
What does observability for AI look like?
You need to be able to answer "what happened?" for any single answer a user received.
- Traces: each request from user input through retrieval, model calls and tools to the final answer.
- Versioning: which prompt, model and settings produced it.
- Logs with care: stored with sensitive data redacted and with a retention period you choose.
- Feedback capture: thumbs, corrections and escalations linked back to the trace, so real failures flow into the eval set.
- Dashboards and alerts: error rates, latency, cost and quality signals, with alerts you can act on.
How does an engagement work?
- Free intro call (about 30 minutes). You describe the feature, how it is built and what worries you. We tell you honestly whether we can help.
- Scoped quote. After the call we give a quote based on what is needed. There is no price list.
- Assessment. We review the prompts, code, data flow, logs and bills, and give you a written list of findings ranked by risk.
- Evals and observability first. So that every later change can be measured.
- Guardrails, cost and latency work. In the order the assessment justifies.
- Hand-off or ongoing sprints. Documentation and training for your team, or continued work together.
You can stop after any stage. We do not promise durations up front. We describe each stage in the quote.
What do you get at the end?
- A written assessment of the current setup with findings ranked by risk.
- An eval set and a runner that fits your CI, so changes are checked before release.
- Guardrails implemented for the agreed risks, with notes on what they do and do not cover.
- Usage, cost and latency tracking per feature, with budgets and alerts.
- Tracing and logging with sensitive data handled as agreed.
- Documentation and a walkthrough for your team, or a sprint plan if we continue together.
What will Right.Link not do?
- We will not promise that the model will never be wrong. We make errors visible, measurable and less costly.
- We will not claim a change is an improvement without running the evals.
- We will not log or copy your users' data beyond what the agreed scope needs.
- We will not tie you to one provider or tool. The setup is meant to survive a change of model or vendor.
Book a free 30-minute intro call
If this sounds like your situation, Book a free 30-minute intro call. Bring a short description of the process or product and what goes wrong today. You will leave with an honest view of whether we can help and what a sensible first step would be. The quote comes after the call and depends on what is needed.