23.10.26

Filling a Contract Agentic AI Developer Role for a Fintech Lending Platform

Overview

A Manchester-based fintech lending platform needed a contract Agentic AI developer who could genuinely build and manage multi-agent production systems — not someone who could recite the vocabulary in an interview. The brief called for strong TypeScript, working Go capability, and hands-on experience with agentic architectures spanning model orchestration, tool use, and memory. We (Dcoded) sourced and placed a candidate with 12+ years of TypeScript experience and direct principal-level ownership of an agentic voice system in production, navigating a hybrid Manchester work requirement and a candidate simultaneously fielding other offers.

The Challenge

"Agentic AI experience" has become one of the most inflated lines on a CV. Every candidate who has called an LLM API in the last eighteen months now describes themselves as an agentic AI engineer, which leaves hiring teams at fintech companies — where the cost of a bad technical hire on a live lending platform is measured in delivery delay and regulatory exposure — unable to trust the CV as a filtering tool on its own.

Our client, a Manchester-based fintech, needed a contract developer who could work across TypeScript and Go and who had genuinely built agentic systems, not just consumed an agent framework's documentation. The role required someone comfortable with the full stack of an agentic production system: the model layer, tool orchestration, and memory management, plus the harder, less glamorous problem of verifying agent output in a domain where an unpredictable LLM response isn't just an inconvenience — it's a compliance risk.

Two additional constraints shaped the search. First, the role was hybrid, requiring time on-site in Manchester — a requirement that immediately narrows the pool once you're speaking to candidates based elsewhere in the UK. Second, the client couldn't be named to candidates at the outset of the process, which meant we had to build trust in the opportunity itself — the technical brief, the seniority of the work, the credibility of Dcoded as the intermediary — before the fintech's name was even on the table.

The Approach

Rather than screen against keywords, we built the conversation around a candidate's ability to describe agentic systems in mechanistic detail — what the model layer actually did, how tools were invoked, how memory was structured, and how output was verified in production. This is the difference between a candidate who has read about agentic AI and one who has shipped it.

In practice, this meant probing three things in sequence: language depth, agentic system ownership, and output-verification methodology. On language depth, we asked directly what the candidate used day-to-day on the back end, rather than accepting the CV's skills list at face value. On agentic system ownership, we asked not just "have you worked on agentic AI" but what kind, and whether the candidate was involved in building the agent versus managing an existing one — a distinction that separates genuine engineering ownership from adjacent exposure. On verification methodology, we asked how a candidate manages output verification for agentic AI specifically, because this is the question that a buzzword-fluent but hands-off candidate cannot answer with any specificity.

We also treated the hybrid Manchester requirement as a negotiation to manage early and transparently rather than a late-stage surprise, and we ran the process in parallel with the reality that strong contract candidates in this space are rarely evaluating a single opportunity at a time.

Implementation

The candidate we placed, based near Heathrow, was found via direct outreach on the strength of a CV showing recent principal AI engineering work. Our first step was to confirm the fundamentals: primary back-end languages, and specifically whether Go — a stated preference in the brief — was workable even if it wasn't the candidate's strongest area. The candidate's own account was direct: Node and Python were the most-used languages, Go experience was lighter, but the candidate assessed themselves as able to switch to Go if the role required it. TypeScript, by contrast, was a 12-year-plus strength, sitting inside 16-plus years of JavaScript experience overall.

From there, we moved into the core of the vetting: the candidate's most recent role as a principal AI engineer building a voice system. We asked directly whether that work was agentic, and the candidate confirmed it was — describing a production system using the model layer, tools, and memory as core components, and confirming direct involvement in building the agentic system rather than simply operating one built by someone else.

The output-verification question is where the candidate's answer went beyond what a surface-level familiarity with the space could produce. The candidate named specific observability tooling — LangSmith and LangFuse — and explained their function: monitoring what an LLM returns, observing input against output, and iteratively refining based on that feedback loop. Critically, the candidate articulated why this matters in a way that showed genuine engineering judgment: in conventional software development, correct-looking output is usually correct output, but in an LLM-driven system, output can look fine on the surface without being the intended reply — meaning manual testing has to sit alongside automated observability, not replace it.

On location, we addressed the hybrid Manchester requirement head-on rather than deferring it. The candidate, based near London, was asked directly how they'd manage two days a week on-site in Manchester. Rather than treat this as a hard blocker, we worked through the practical shape of the arrangement together — the candidate proposed clustering on-site time into three or four consecutive days rather than scattering it across the week, which we agreed was workable within the flexibility the client had around scheduling.

Results & Impact

The vetting conversation surfaced a candidate whose experience matched the brief on every axis that mattered to the client:

• 12+ years of TypeScript experience, sitting inside 16+ years of broader JavaScript work — a strong match against the client's stated language priority

• Confirmed hands-on ownership of an agentic production system as a principal AI engineer, including the model layer, tool orchestration, and memory components — not just exposure to agentic concepts

• A working, specific methodology for agentic output verification, naming LangSmith and LangFuse and articulating the distinct challenge of validating non-deterministic LLM output against software-development norms

• Workable flexibility on Go, with the candidate self-assessing as able to transition from a Node/Python-primary background given the strength of their broader back-end experience

• A practical resolution to the hybrid Manchester requirement, with the candidate proposing a clustered on-site schedule that worked within the client's flexibility around specific in-office days

The distinction that mattered most in this placement was the gap between a candidate who could describe agentic AI in the abstract and one who could describe why output verification for agentic systems is a different engineering problem from conventional software testing. That distinction only surfaces when the interviewer knows what question to ask next — and it's the difference between a fintech client discovering a capability gap after the contract starts and discovering it before an offer is made.

Key Takeaways

For CTOs and Heads of AI hiring into agentic AI roles, this placement points to a few concrete lessons:

• Ask about verification, not just architecture. Any candidate can describe a model layer, tools, and memory in the abstract. Fewer can explain how they've handled the specific problem of validating non-deterministic LLM output in production — naming real tooling (LangSmith, LangFuse) and describing a genuine iterative refinement process.

• Separate "built" from "managed." Ask directly whether a candidate was involved in building an agentic system or simply operating one that already existed. The two produce very different CVs and very different day-one capability.

• Treat secondary language requirements as a flexibility question, not a hard filter. Our candidate's Go experience was lighter than their TypeScript depth, but their broader back-end range across Node and Python supported a credible case for fast adaptation — a distinction worth exploring rather than screening out on a CV keyword mismatch.

• Address hybrid work constraints early and specifically. Location friction is easiest to resolve when it's raised directly and worked through collaboratively — in this case, by restructuring on-site days into consecutive blocks rather than a fixed weekly pattern.

• Don't let confidentiality slow down trust-building. Where a client's name can't be shared upfront, being transparent about sector and role complexity (in this case, confirming the fintech and Manchester basis early) keeps the conversation moving without compromising the client's position.

Genuine agentic AI experience shows up in how a candidate talks about failure modes and verification, not in how fluently they use the term. If your organisation is hiring for agentic AI capability and you want that distinction tested properly before a candidate reaches your team, that's the conversation we're built to have.