The forward-deployed engineer who owns the model layer: retrieval, tool use, agents, evaluations and cost, built inside your team and handed over documented.
Why this role exists
A model demo is easy. Making an agent answer from your real documents, call your real systems, stay inside its permissions and hold up under users is the hard part, and it needs an engineer who lives in that layer.
Most teams do not need a full AI department. They need one senior engineer who owns prompts, retrieval, tools and evaluations end to end, works inside their codebase, and leaves the system running without us. That is exactly what this role is.
What this engineer owns
The engagement starts with a single senior engineer inside your team and grows only when the problem justifies it. These are the commitments behind the role; exact scope is agreed with your team.
Your agent engineer owns the part of the product where the model meets real users: prompts, retrieval, tool calls, streaming responses and the interface around them. They write the code, wire the model to your systems, and stay answerable for how it behaves.
What to verify: Ask which parts of the prompt, retrieval and tool layer the engineer will personally own, and who reviews changes before they ship.
They build agents that plan, call your tools and APIs, and return work your team can check: drafting with citations, updating records, running approved workflows. Tool permissions are explicit, and actions that matter stay behind human approval.
What to verify: Ask which tools the agent can call, what each tool is allowed to do, and which actions require a human to confirm before anything happens.
Answers are only as good as what the model can see. They design the retrieval layer: chunking, indexes, metadata filters and freshness rules, so responses come from your actual documents and systems rather than from memory.
What to verify: Ask how documents get indexed, how stale content is handled, and how a response proves which sources it used.
They build a small eval set from your real cases and run it on every change, so prompt or model updates are judged on evidence. Failures become test cases instead of anecdotes.
What to verify: Ask to see the eval set, how failures are added to it, and what numbers gate a change from test to production.
They track tokens, cache hits and response times per feature, and tune the path so the fast cases stay fast and the hard cases escalate to stronger models or a human. Model choice is a decision with numbers, not a default.
What to verify: Ask for the per-feature cost and latency figures and how model fallbacks are decided.
Every prompt, tool schema, eval and decision lives in your repository with written rationale. When the engagement ends, your team runs and improves the system without us in the loop.
What to verify: Ask where prompts, evals and tool definitions live, and who on your side can change them after handover.
How they work
The loop is simple and strict: plan the change, act on real data, observe what actually happened, and verify against an eval set before anything ships.
AI in the engagement
AI is not a separate offering bolted on. It is the material this engineer works in, and the judgment they bring is part of what your team absorbs.
Prompts, retrieval and evals are written so the model is a swappable part. When a better or cheaper model appears, changing it is an afternoon, not a rebuild.
The engineer treats an answer without sources as a draft, not a result. Retrieval quality is tuned before response phrasing is.
Every bad output in production is captured, labelled and turned into an eval case, so the same failure class gets caught before the next release.
Actions that move money, data or customer commitments require explicit human approval. The agent prepares the work; a person confirms it.
Working principles
Written scope, reviewed changes and visible trade-offs decide whether an embedded AI engineer actually works. We make those commitments explicit rather than implied.
The agent's capabilities, tool permissions and escalation rules are written down before the first commit, and changes to them are agreed, not assumed.
Prompt changes, retrieval changes and tool changes go through the same review and eval gate as code. Nothing reaches users because it 'seemed better'.
When accuracy, cost and speed conflict, the engineer shows the numbers and lets you decide, rather than picking quietly.
You work with the same engineer for the engagement, not a rotating bench. Continuity is what makes judgment about your domain compound.
Security & trust
This role touches your data, your systems and your customers. Access, data boundaries and agent permissions are agreed in writing before the first commit.
The engineer gets scoped access to the systems the work needs, nothing more, and access is reviewed and revoked at the end of the engagement.
Provider settings are configured so your content is not used to train models. Self-hosted or private deployments are supported when the data cannot leave your boundary.
Tool calls, approvals and outputs are logged so any action an agent took can be traced after the fact.
Keys live in your secret manager, never in code or prompts, and are rotated when the engagement ends.
Working arrangements
The engineer works remotely inside your rituals, in your cloud and your repositories, with model access routed through accounts you control.
The engineer joins your stand-ups, reviews and planning from remote, and works in your repositories and issue trackers as a team member would.
Model calls run through your accounts, with your keys and your logging. We do not route your data through infrastructure you have not approved.
What the system may read, what it may send to a model provider and what it must never send are agreed in writing before development starts.
For workshops, evaluations with your domain experts or a critical go-live, on-site time is arranged deliberately.
How it starts
A paid two-week sprint proves the working relationship before anything longer is discussed. If it does not show real progress, you walk away.
Week one starts with the real cases: what users ask, which systems the agent must touch, and where a wrong answer hurts. The engineer sits with your team and reads the actual workflows.
One goal in writing: for example, a working agent for one workflow, grounded in your data, with a defined eval set and explicit tool permissions. Success criteria are agreed before building starts.
The engineer builds inside your codebase, runs the eval set on every change, and shows you the real outputs, including the failures, at the end of each week.
At the end of the sprint you see the eval numbers, the cost per task and the failure cases, and decide together what comes next: extend, hand over or stop.
Whichever fits the work. The engineer is model-agnostic and works with the major commercial providers and open-weight models, including self-hosted deployments when your data cannot leave your environment. Model choice is revisited with evidence as the landscape changes.
Yes. The role exists to work inside your team, so they build in your languages, your framework and your cloud, and use the model tooling your compliance rules allow.
They live in your repository from day one, with written rationale for the non-obvious decisions. Nothing about how your system behaves is held only in our heads.
Tool permissions are explicit and narrow, consequential actions require human approval, and every action is logged. The agent's boundaries are part of the written scope, not a prompt afterthought.
No, but someone on your side owns the outcome. The engineer works with your domain experts to define what a good answer looks like, and hands the system to your team with documentation and evals.
The sprint is a fixed, paid engagement agreed before it starts, and its scope is written down. If it does not show real progress, you walk away with everything built so far in your repository.
Let's talk
Tell us about the workflow, the data and the constraints. We will help define a first sprint goal and the evidence needed to judge it.