Applied AI & Agents
AI that does work, not demos.
Prompt engineering is the visible ten percent. The rest is retrieval, tools, evals and guardrails: the engineering that turns a model into a colleague you can trust near production.
- Models
- hosted or open-weight
- Actions
- via your pipelines
- Measured by
- an eval set, not vibes
Interactive
Watch an agent earn its keep
Pick what walks in the door. The loop is the same every time: gather context, reason against a schema, use ordinary tools, pass a gate, produce something a person can act on. What changes is how much of it needs a human.
- 01
Gather context
waitingRetrieval over runbooks, docs, past incidents and live read-only queries.
- 02
Reason
waitingThe model forms a plan against a structured output schema. No free-form guessing.
- 03
Call tools
waitingThe same Ansible jobs, Terraform plans and APIs a human would use. Nothing bespoke, nothing hidden.
- 04
Guardrails & approval
waitingPolicy checks, blast-radius limits, then a human decides on anything that changes state.
- 05
Outcome
waitingA PR, an enriched ticket, an answer with citations. Logged, auditable, measurable.
Notice what the agent never does: it never gets a shell, never applies a change itself, never answers without a source. That restraint is the product. An agent you can trust near production is one whose worst day is a rejected PR.
What you are actually buying
Prompt engineering is the visible ten percent
A good prompt gets you a demo in an afternoon. Everything below the waterline is what gets the demo through its first month in production. Skip a layer and you find out which one it was, usually in front of a customer.
- 01
Evals
A test set of real inputs with known-good answers. Without it, 'it seems better' is the only metric, and it isn't one.
- 02
Structured outputs
Schemas the model must fill, so the result can be validated and handed to code, not read by a human and retyped.
- 03
Retrieval
Getting the right five paragraphs in front of the model, from your documents, not the internet's.
- 04
Tool design
Small, boring, well-described tools. Most agent failures are tool failures wearing a model costume.
- 05
Guardrails
Policy checks, blast-radius limits and approval gates that decide what the model may do, not just what it may say.
- 06
Cost & latency budgets
Model routing, caching and prompt trimming so the bill and the wait stay predictable at real volume.
- 07
Observability
Every call traced: inputs, outputs, tokens, tool results. When it misbehaves you can see why, not guess.
- 08
Versioning
Prompts, schemas and eval sets in git, released like software, so a change that regresses can be rolled back.
Use cases
Where it pays for itself
Each of these is a bounded job with an obvious measure of success. That is not an accident. The best AI projects look boring on a slide and remarkable on a timesheet.
Alert triage with a proposed fix
buys you · The 3am page arrives with the cause, the runbook section and a ready-to-approve remediation.
Runbook copilot for on-call
buys you · The engineer asks in plain language and gets the exact procedure, with the commands filled in for that host.
Documentation Q&A with citations
buys you · Answers that point at the paragraph they came from, or say 'not documented' instead of inventing one.
Ticket enrichment and routing
buys you · Every ticket lands on the right team already carrying the affected service, recent changes and similar cases.
PR and change generation, reviewed
buys you · Routine changes drafted as pull requests against your checklist. Humans review; they no longer type.
Extraction from PDFs and email
buys you · Invoices, forms and contracts become validated records in your systems, with the source page attached.
Internal assistants over your knowledge
buys you · One place to ask about policies, systems and history, scoped to what each person is allowed to see.
Something not on the list?
If it has inputs, a correct answer and a system to land in, it is probably a good fit. Tell us what you were told AI couldn't do.
Describe it →Trust
Your data stays yours
There is no single right answer to where the model lives, only trade-offs between capability, control and cost. We lay them out plainly, pick per use case, and put the same controls in front of every route: redaction, no-training terms, and an audit log of every call.
Hosted frontier models
private endpoint
+ Best raw capability, fastest to start, no GPUs to run.
− Data leaves your network (encrypted, under a no-training agreement). Per-token cost at volume.
Open-weight models, your infrastructure
on-prem or your cloud
+ Nothing leaves. Fixed cost. Works in air-gapped estates.
− You run and patch the serving stack. Capability trails the frontier for hard reasoning.
Hybrid routing
policy decides per request
+ Sensitive requests stay local, hard ones go out. Cost and control tuned per use case.
− Two stacks to observe. Routing rules become something you must maintain and test.
How it ships
From idea to production
Each rung earns the next. Nothing gets tools until it has evals; nothing gets guardrails until it has tools worth guarding. The order is the method.
- 1
Prototype
day 1
A working slice against real data. If it can't impress in a day it won't improve in a quarter.
- 2
Eval set
week 1
Fifty real inputs with agreed answers. Now every change has a score, not an opinion.
- 3
Retrieval
week 1–2
Your documents, chunked and indexed, so answers come from your reality and can be cited.
- 4
Tools
week 2
Read-only first. The agent can look before it is ever allowed to touch.
- 5
Guardrails
week 2–3
Policy, blast-radius limits and an approval gate for anything that changes state.
- 6
Monitoring
week 3
Traces, cost, latency and eval scores on a dashboard. The same discipline as any other service we run.
- 7
Hand over
yours
Prompts, schemas, evals and infra in your repos. A walkthrough. An engineer who still answers.
Straight answers
Questions we get asked
Will it hallucinate? +
Yes. Every model does, which is why we never rely on the model alone. Retrieval gives it your facts, citations make claims checkable, evals measure how often it is wrong, and an approval gate sits in front of anything that changes state. The design assumes mistakes and makes them cheap and visible.
Which model do you use? +
Whichever fits the job. Hosted frontier models (Claude, OpenAI's models and others) for hard reasoning; open-weight models on your own infrastructure where data cannot leave; often a mix, routed by policy. We build against an abstraction so swapping models is a config change measured by your eval set, not a rewrite.
Can it run on-prem or in our cloud? +
Yes. Open-weight models serve well on a single GPU node for most internal workloads, and the retrieval, tooling and guardrail layers are ordinary services we deploy with the same Terraform and Ansible as everything else. Air-gapped estates are fine.
How do you know it works? +
An eval set: real inputs from your environment with agreed correct outputs, scored automatically on every change. We track faithfulness, task success, human edit rate and cost per task. If a number does not move, the feature does not ship.
What does it cost to run? +
Usually less than people expect and more than the demo suggested. We set a cost and latency budget per use case up front, then meet it with model routing, caching and prompt trimming. You see cost per task on the same dashboard as accuracy.
Can it touch production? +
Only through the same automation and approvals a human would use. The agent proposes; a pipeline or a person applies. Read-only tools first, state-changing tools behind a gate, everything logged. It never gets a shell.
Next step
Tell us what you were told AI couldn't do.
Bring the job, the data and the doubt. We'll prototype against your reality within days and tell you honestly whether it's worth taking further.