Ship a public agent and eval harness as your 2026 proof of work

What you need to know

The market for AI engineers in 2026 is crowded at the entrance and thin at the bar. Thousands of people can write a prompt, wire up a model call and put "built an LLM application" on a CV. Very few can show that the thing they built actually works, on cases they did not cherry-pick, measured against a target they set in advance. That gap is where you get hired.

The single most convincing proof of work is not a line on a CV and not a certificate. It is a shipped, public artefact: a small agent that does one real job, sitting in an open repository, accompanied by an eval harness that proves the agent does that job well. Commits, pull requests and a documented eval are public and unfakeable. They demonstrate the whole loop a hirer is buying — that you can scope a problem, build a solution, measure it honestly and communicate what you found — rather than asserting it.

The differentiator, and the part almost everyone skips, is the eval harness. A demo shows your agent succeeding once, on an example you controlled. An eval harness shows how often it succeeds across a set of cases anyone can run, and it names the failures you have not fixed yet. Most candidates ship the demo. The ones who ship the evidence stand out immediately, in Bengaluru and Bristol alike, because they are showing the exact competence the job requires. This guide walks the full path: pick the artefact, build it in the open, write the eval that proves it, package it for hirers, and — the step that decides whether any of it matters — get it in front of the people doing the hiring.

Why a shipped artefact beats a CV

A CV is a set of claims you are asking a stranger to trust. "Built a retrieval-augmented chatbot", "improved model accuracy", "shipped an agent to production" — every hirer has read a hundred of these, and none of them can be verified from the page. The reader has to take your word for the scope, your word for the result, and your word for how much of it was actually you. In a market this crowded, unverifiable claims are noise.

A public artefact inverts that completely. When your work lives in an open repository, the evidence is the object itself. The commit history shows the problem being scoped and the solution taking shape over days, not appearing fully formed. The pull requests show you responding to review, splitting work sensibly, and thinking in reversible steps. The README shows your reasoning. The eval results show the outcome, with the failures left visible rather than airbrushed out. None of this can be faked into existence the night before an interview — that is exactly why it is worth so much more than a bullet point. A hirer does not have to trust you; they can read you.

This matters because of what hirers are actually screening for. They are not buying a demo that worked once. They are buying judgement: can this person take an ambiguous problem, cut it down to something shippable, make the tradeoffs a real system forces, measure whether it worked, and explain all of that to a team? A shipped artefact with a documented eval is the only format that shows every link in that chain at once. It is the closest a candidate can get to letting the work speak for itself. If you are early in this and want the foundational version of the argument, our guide on landing your first AI engineer role with open-source proof of work covers why public commits beat credentials in the first place.

There is a second-order benefit worth naming. A public artefact is discoverable. A CV sits in an inbox until someone opens it; a repository linked from a public profile can be found by a hirer who is actively browsing for talent. That is the difference between waiting to be shortlisted and being found — and it is why, once you have built the thing, the last mile is putting it somewhere hirers look. If you already have an artefact worth showing, you can claim a free Verified Builder profile and attach it in a couple of minutes.

Pick the artefact: one real job, done well

The most common mistake is ambition in the wrong direction. Candidates reach for a broad, impressive-sounding assistant — "an AI agent that manages your whole workflow" — and end up with something that does ten things badly and proves nothing. The artefact that gets you hired is the opposite: a scoped agent that does one real job, for a real user, in a way you can measure. Narrow is not a limitation here; it is the whole strategy, because a job you have defined tightly is a job you can actually evaluate.

Good artefacts share four properties, and the difference between a strong and a weak idea is usually visible before you write a line of code. Use this comparison as a filter.

Property	Strong proof-of-work artefact	Weak proof-of-work artefact
Scope	One job: triage inbound support tickets into three queues with a reason	A general assistant that "helps with anything"
Real users	Solves a task a real person or team actually does today	A toy problem invented to show off a framework
Measurable	Has a clear right answer you can score against a golden set	Open-ended output nobody can grade objectively
Documented	README walks the decisions; eval results are published	A demo GIF and a one-line description

Turn those four properties into a scoring rubric you apply to every idea before committing. Score each candidate artefact one point per row — Is it scoped to one job? Does it serve a real user or task? Can its output be measured? Can the decisions be documented? An idea that scores four is worth building. An idea that scores two or less will not survive contact with an eval, because you will not be able to define what "working" means. Spend a day on this rubric and you save a fortnight building something unprovable.

Concrete artefacts that score well and map onto real Indian and UK use cases: an agent that classifies and routes customer support emails for a small D2C brand; an agent that extracts structured fields from GST invoices or UK VAT receipts into a clean table; an agent that answers policy questions over a single council's published documents; an agent that reviews pull requests for one specific house rule. Each has a right answer, a real user, and a natural golden set. And if the "one real job" you want to show is integration rather than reasoning, building a tool the agent calls is itself a strong artefact — our walkthrough on how to build your first MCP server with FastMCP in twelve steps takes an integration from empty file to working tool you can then wrap and evaluate.

Build it in the open

Once you have the artefact, how you build it is part of the proof. Building in the open — a public repository from day one, regular commits, honest progress notes — turns the work into a visible record of how you think, which is precisely what a hirer wants to read. A repository that appears fully formed in a single commit tells them nothing about your process. A repository that grows over three weeks, with each commit doing one comprehensible thing, tells them everything.

Repository hygiene is not cosmetic; it is a signal of professional habits. Keep the commit history clean and legible, with messages that say why, not just what. Structure the project so someone can find the agent, the eval and the data without a guided tour. Include a licence, pin your dependencies, and add a single command that runs the whole thing from a clean checkout — nothing erodes trust faster than a repo that will not run. These are the same habits a team will expect on their codebase, so demonstrating them here is a direct preview of what you would be like to work with.

The README carries more weight than any other file. It should not be a feature list; it should walk the decisions. State the problem in a sentence. Explain the approach and, crucially, the tradeoffs — why this retrieval strategy over that one, why you capped the tool calls, what you deliberately left out and why. Show how to run the agent and how to run the eval. A hirer who reads a README that reasons out loud has, in five minutes, learned more about your engineering judgement than a whole interview round would surface. Documented thinking and honest tradeoffs are the currency here, and the README is where you spend it.

Build-in-public updates amplify all of this at almost no cost. A short weekly note — on a personal blog, a Builder profile, or a public thread — saying what you tried, what broke, and what the eval said this week does two things. It creates a timeline that proves the work is yours and ongoing, and it forces you to articulate your reasoning while it is fresh. You do not need an audience for this to work; the record itself is the point. When a hirer later finds the finished artefact, the trail of honest updates behind it is what makes it credible.

Write the eval that proves it

This is the section that separates you from the field. Almost everyone can produce a demo. Almost nobody ships the eval that turns the demo into evidence. A demo is a single successful run on an input you chose; an eval harness is a repeatable measurement of how the agent performs across a set of cases anyone can execute. The first is a claim. The second is proof. If you build only one thing on this list to a high standard, build this.

An eval harness has three parts. First, a golden set: a collection of input cases with their expected outcomes, chosen to cover the ordinary path, the awkward edges, and the cases you expect the agent to get wrong. Twenty well-chosen cases beat two hundred lazy ones — every case should test something specific. Second, a metric: a defined way to score each run, whether that is an exact match on a routing label, a check that the extracted fields are correct, or a rubric applied by a stronger model acting as judge. Third, a runner: code that loads the cases, runs the agent on each, scores the result and prints a report. The runner is what makes the eval reproducible — a hirer clones the repo, runs one command, and sees the same numbers you did.

Here is a minimal harness sketch. It is deliberately small; a real one would add cost tracking, retries and per-case logging, but the shape is exactly this — load cases, run the agent, score, report.

# eval.py — a tiny agent eval harness
import json
from pathlib import Path
from my_agent import run_agent  # your scoped agent's entry point

def load_cases(path="golden_set.jsonl"):
    """Each line: {"input": ..., "expected": ...}"""
    with open(path) as f:
        return [json.loads(line) for line in f if line.strip()]

def score(expected, actual):
    """Swap in your metric: exact match, field-level F1, or an LLM judge."""
    return 1.0 if actual.strip().lower() == expected.strip().lower() else 0.0

def main():
    cases = load_cases()
    results, failures = [], []
    for i, case in enumerate(cases):
        actual = run_agent(case["input"])
        s = score(case["expected"], actual)
        results.append(s)
        if s < 1.0:
            failures.append({"i": i, "input": case["input"],
                             "expected": case["expected"], "actual": actual})

    passed = sum(results)
    total = len(results)
    print(f"Score: {passed}/{total} = {passed / total:.1%}")
    Path("failures.json").write_text(json.dumps(failures, indent=2))
    print(f"Wrote {len(failures)} failing cases to failures.json for review.")

if __name__ == "__main__":
    main()

Notice what the harness does beyond producing a headline number: it writes out the failing cases. That failures file is one of the most convincing artefacts you can publish, because it shows you looking your own weaknesses in the eye rather than hiding them. A hirer who sees an honest eval that reports, say, "84% on the golden set, with the failures concentrated on multi-issue tickets" trusts you far more than one who sees a suspiciously perfect demo. The point of the eval is not to prove the agent is flawless. It is to prove you can measure, and that you know where it stands.

Choosing the right metric is where most of the real thinking lives, and it depends on what your agent produces. A routing agent can use exact-match accuracy; an extraction agent wants field-level correctness; an agent that generates prose needs a rubric, often applied by a model acting as judge. Agents that take multiple steps need more than an outcome check — you often want to score the trajectory and the tool calls, not just the final answer. Our guide on how to evaluate AI agents across trajectory, tool calls and outcome goes deep on picking and combining these signals, and it pairs directly with this harness. If you want to turn the whole practice into a portfolio in its own right, our companion piece on building an evals portfolio that proves your work shows how to make measurement the headline skill.

Package it for hirers

A repository, however good, asks a busy hirer to do the work of understanding it. Do that work for them. Alongside the code, write a one-page write-up — think of it as the executive summary of the artefact — that a hirer can read in two minutes and come away convinced. It follows a simple shape, and it is worth polishing hard because it is often the first and only thing they read.

Structure the one-pager around five beats. The problem: the one real job, stated in a sentence, with who it is for. The approach: how the agent solves it, at the level of architecture rather than code. The tradeoffs: the decisions you made and what you gave up — this is the section that shows judgement, so do not skip it or soften it. The eval results: the headline number, the metric behind it, and an honest note on where the failures cluster. What you would do next: the improvements you can see but have not made, which shows you understand the artefact is a step, not an endpoint. That last beat quietly signals seniority; junior candidates present finished work, stronger ones present work they know how to keep improving.

A short walkthrough video or Loom is an optional but powerful addition. Two or three minutes of you running the agent, running the eval, and talking through one interesting tradeoff lets a hirer hear you reason in real time — the thing an interview is meant to test, delivered before the interview. Keep it unedited and honest; the point is authenticity, not production value. If you are more comfortable in writing, the one-pager alone is enough. The principle either way is the same: reduce the effort a hirer must spend to see that you can scope, build, measure and communicate. The easier you make that, the more likely the artefact converts into a conversation.

Get it discovered

Here is the uncomfortable truth that undoes a lot of good work: a repository nobody sees does nothing. You can build the perfect scoped agent, write an exemplary eval, and craft a sharp one-pager, and if it sits at a URL no hirer ever visits, it may as well not exist. The final step is not optional and it is not an afterthought — it is where the proof of work either finds an audience or dies quietly in a folder.

The instinct is to drop the link on a job application and hope. The better move is to put the artefact where hirers are already looking for talent. Hiring teams and recruiters across India and the UK increasingly browse for AI Builders directly rather than waiting for applications to land, and a Verified Builder profile on AI Tech Connect is built for exactly that — a public, searchable place to attach your repository, your eval results and your one-page write-up so the proof of work travels with your name. Instead of one application to one company, the artefact becomes discoverable to every hirer browsing the directory. That is the leverage: build once, get found many times.

A profile also does something a bare GitHub link cannot — it frames the work. It carries your name, your location, your verified status and a short bio alongside the artefact, so a hirer landing on it sees a person and a body of evidence together, not an orphaned repository. Link the code, embed the eval numbers, and point to the walkthrough. When a recruiter in Manchester or a founder in Hyderabad is shortlisting, the profile is what turns your artefact from something they would have to stumble upon into something the directory surfaces for them.

Putting it together

The proof of work that gets you hired as an AI engineer in 2026 is not a claim — it is an object. Pick one real job with a clear right answer and score it against the four-property rubric before you build. Build it in the open, with a clean history and a README that reasons out loud. Then write the eval that proves it works: a golden set, a metric, a runner anyone can execute, and a failures file you are not afraid to publish. That eval is the differentiator, because most candidates ship the demo and almost none ship the evidence. Package the whole thing into a one-page write-up a hirer can read in two minutes. And put it where hirers look — on a Verified Builder profile, so the artefact is found rather than filed. Do that, and you stop asking strangers to trust a CV bullet. You let the work prove itself.