Hire on Metaheuristic - Applied AI partner

Agentic AI engineer

Mon, 01 Jan 0001 00:00:00 +0000

An agent is not a prompt. It is a control loop with money attached: a model decides, a tool runs, state changes, and the loop goes around again. Everything that makes agents hard is in that sentence - non-determinism at the decision point, side effects at the tool boundary, and unbounded cost in the loop.

Hiring an agentic AI engineer means hiring someone who treats that loop as a distributed system rather than a clever prompt.

AI agent developer

Mon, 01 Jan 0001 00:00:00 +0000

The demo took a weekend. The production version has been “two weeks away” for a quarter. Between them sits work nobody demoed: authentication into six internal systems, a queue that survives a deploy, an approval screen for the cases the agent should not decide alone, and a test suite that catches the regression before your customer does.

An AI agent developer is the person who does that work.

What gets built

The agent

Planning and tool-calling loop, scoped to a task small enough to verify. Budgets, retries, cutoffs, and an escalation path to a human when confidence or permissions run out.

CV

Mon, 01 Jan 0001 00:00:00 +0000

I build systems where a language model plans, calls tools, and acts - and I make those systems measurable, safe and cheap enough to point at production traffic.

The work is closer to distributed systems engineering than to modelling: control flow with real budgets, tool contracts that survive an unreliable caller, retrieval that respects your permission model, an eval harness that turns prompt changes into diffs with numbers attached, and traces that make a 3am diagnosis possible.

Job description template

Mon, 01 Jan 0001 00:00:00 +0000

Most agentic AI engineer job descriptions are a list of framework names. That screens for people who have read the documentation and against people who have been paged at 3am by a loop that would not stop. Here is a version that does the opposite.

The template

Agentic AI Engineer

You will design and ship systems where a language model plans, calls tools, and takes real actions against real data - and you will make those systems measurable, safe and cheap enough to run at our volume.

LLM engineer

Mon, 01 Jan 0001 00:00:00 +0000

The model is the cheapest part of your system to change and the most expensive part to change blindly. An LLM engineer is the person who makes that change measurable: prompts under version control, an eval suite that runs in CI, a cost model per task, and a routing layer so no single vendor is load-bearing.

The work

Evals first

A golden set drawn from real traffic, pass criteria written by whoever owns the outcome, and a regression gate in CI. Once that exists, prompt changes stop being arguments and become diffs with numbers attached. Before it exists, every release is a vibe.

RAG engineer

Mon, 01 Jan 0001 00:00:00 +0000

Retrieval-augmented generation is easy to demo and hard to run. The tutorial version - split on 500 characters, embed, cosine similarity, top five - works beautifully on a clean corpus with no access control and no deadlines. Your corpus is not clean, your documents belong to different people, and half of them were scanned in 2019.

A RAG engineer is hired for the distance between those two situations.

What breaks in production, in order of frequency

Parsing. The PDF pipeline drops table structure, so a number loses its column header and the model confidently misreads it.
Chunking. Fixed-size splits cut clauses in half. Contract language, policy documents and specifications are hierarchical, and the chunker should be too.
Permissions. The demo searched everything. Production must not, and post-filtering leaks.
Freshness. Nobody defined how stale is too stale, so the index quietly drifts a quarter behind the source of truth.
Ranking. Pure vector similarity retrieves topically related but useless passages. Hybrid search plus a reranker usually beats a better embedding model.
No retrieval evals. Quality is discussed rather than measured, so every change is a guess.

What gets built

Ingestion

Layout-aware parsing, OCR where needed, table and structure extraction, deduplication, and a pipeline that is re-runnable and incremental rather than a one-off script someone ran in a notebook.

Rates & engagement models

Mon, 01 Jan 0001 00:00:00 +0000

Four shapes

1. Architecture review - 1 to 2 weeks

For teams with something already running that is slow, expensive, unreliable, or about to meet a security review. You get a written teardown: failure taxonomy from your own traces, eval and guardrail gaps, a cost and latency model, and a prioritised fix list with effort estimates. Fixed fee. No obligation to continue.

2. Discovery Sprint - 2 to 4 weeks

For teams who know the outcome they want and not the path. You get a working thin slice, an architecture your engineers can build against, an eval harness, a security pre-check, a cost and latency model, and a roadmap your board can read. Fixed fee, credited against a build.