AI Agents Portfolio: 5 Projects That Get You Hired

I have reviewed more agentic AI portfolios than I can count over the last eighteen months, and a pattern has emerged that I want to share. The candidates who get offers do not have the most polished GitHub pages, the most impressive demos, or the longest CVs. They have two or three projects that demonstrate specific engineering judgements, written up in a way that lets a senior reviewer see how they think.

In this article I walk through the five projects I most consistently recommend candidates build in 2026. Each one is buildable in three to six weeks of focused work alongside a job, each one demonstrates a distinct set of skills, and each one can be written up in a way that survives senior-engineer scrutiny.

I will also cover the write-up template I use, the GitHub presentation patterns that work, and the most common portfolio mistakes I see. If you are early in your agent engineering journey, building two of these five and presenting them well will get you significantly further than reading another framework tutorial.

The goal is not to build a product. The goal is to demonstrate craft. That distinction shapes everything that follows.

When I review a candidate’s application for an AI Agent Engineer role, I spend roughly 30 seconds on the CV and up to 30 minutes on the portfolio. The CV tells me where you have been; the portfolio tells me what you can actually do.

This asymmetry is particularly stark in agentic AI because the field is too new for CV signals to be reliable. A title like “ML Engineer at FAANG” does not tell me whether you can ship a production agent, because most engineers with that title have not. Conversely, a “Backend Engineer at a small startup” who has shipped three thoughtful agent projects is often the strongest candidate in the pool.

In 2026, your GitHub portfolio is the single most predictive signal of agent engineering ability.

This puts portfolio work on equal footing with formal experience for most hiring loops. It also creates an enormous opportunity for candidates who invest in it deliberately.

The projects I describe below are not toys. They are reference architectures that demonstrate the specific judgements senior engineers look for: scope discipline, evaluation rigour, observability, cost awareness and clean engineering. Each one is buildable, but each one rewards thoughtful execution.

Before listing projects, the criteria I use to judge whether something is worth building.

Specificity over generality. A project that solves a narrow, well-defined problem is more impressive than one that “does AI stuff”. The narrower the scope, the easier it is to demonstrate craft.

Evaluation built in. A project without evaluation is a demo. A project with evaluation is engineering. Always include an eval suite, even a minimal one.

Visible reasoning. The reviewer should be able to read your code or write-up and see why you made each design choice. Comments, READMEs and architectural diagrams are essential.

Reproducibility. If a reviewer cannot run your project in 15 minutes, you have a problem. Spend time on setup ergonomics.

Production-shaped. Even if you do not deploy to production, structure the project as if you would. Error handling, retries, structured logging, configuration, all matter.

The five projects below are chosen to demonstrate these criteria across a range of domains. None of them is novel; the value is in execution quality, not in problem selection.

What it is. An agent that takes a research question, plans a search strategy, gathers and reads sources, and produces a structured report with citations.

Why it is worth building. It is the canonical agentic AI project for a reason. It exercises planning, tool use, retrieval, and synthesis, and the output is something a non-technical reviewer can evaluate qualitatively.

Suggested tech stack. LangGraph or the OpenAI Agents SDK for orchestration. Web search through a paid API or open data sources. A reader component using Claude or GPT for extraction. A synthesiser using the same. Tracing with LangSmith or Braintrust.

Key engineering challenges. Planning quality, retrieval relevance, citation accuracy, and synthesis coherence. Each one is a meaningful sub-problem.

Evaluation strategy. Build a curated set of 20 research questions with ideal answers. Use LLM-as-judge scoring on dimensions like factual accuracy, citation correctness, coverage and structure. Score before and after every meaningful change.

Write-up emphasis. Lead with the planning architecture. Show your trace logs. Discuss the trade-offs between depth and breadth of search.

The strongest deep research agents I have seen as portfolio pieces did one thing exceptionally well: they were honest about limitations.

A research agent that knows what it does not know is more impressive than one that overconfidently produces a 5,000-word essay.

What it is. An agent that operates on a real repository, understands the codebase, and can make scoped changes such as bug fixes or small feature additions.

Why it is worth building. Coding agents are one of the highest-leverage applications of agentic AI in 2026 and demonstrate sophisticated tool use, safety patterns and evaluation discipline.

Suggested tech stack. Tree-sitter or LSP-based indexing for repo awareness. A sandbox for safe execution. Git integration for working in branches. Tools for read file, write file, run tests, run linter. Orchestration with LangGraph or your framework of choice.

Key engineering challenges. Repo indexing strategy, scoping changes to a small surface area, ensuring tests pass, and providing transparent diffs for human review.

Evaluation strategy. Use a public bug-fix dataset such as SWE-bench Lite or a self-curated set of issues from your own past projects. Measure success rate, test pass rate, and human edit distance on the resulting diffs.

Write-up emphasis. Show the safety patterns prominently. Discuss how you prevent the agent from making broad changes, how you gate writes, and how the human stays in the loop. The architecture diagram is critical here.

This project is harder than it looks. Even a basic version that fixes simple bugs in a small repository is a strong portfolio piece. Do not aim for “build Devin”; aim for “fix specific bug categories reliably”.

What it is. An agent that handles tier-one support questions for a real or simulated SaaS product, using a knowledge base and a small set of action tools, with explicit escalation logic.

Why it is worth building. It is the most realistic agentic project for enterprise hiring contexts. It exercises RAG, intent classification, tool use, escalation and observability.

Suggested tech stack. A vector store such as pgvector or Pinecone for the knowledge base. An orchestrator using your framework of choice. Tools for ticket lookup, status checks, refund initiation (mocked). A simple chat UI built with Streamlit or Next.js. Tracing essential.

Key engineering challenges. Intent classification accuracy, RAG relevance, action authorisation, and escalation policy. Each one rewards careful design.

Evaluation strategy. Curate 50-100 historical or synthetic support tickets with labelled correct outcomes. Measure deflection rate, first-contact resolution, and escalation appropriateness. Track confidence calibration: does the agent correctly know when to escalate?

Write-up emphasis. Lead with the escalation policy. The strongest signal of agent engineering maturity is a thoughtful escalation strategy.

A support agent that hits these numbers on a curated dataset is a meaningful portfolio piece.

What it is. An agent that takes a target customer profile, finds matching companies and individuals, enriches them with public data, scores them against the profile, and drafts personalised outreach.

Why it is worth building. It is one of the most directly commercial applications of agentic AI and demonstrates multi-step workflows, data integration and judgement under ambiguity.

Suggested tech stack. Web search and scraping with respect for robots.txt and rate limits. LinkedIn or similar enrichment APIs (paid or simulated). LLM-based scoring. CRM integration with HubSpot, Salesforce or a mock. Orchestration with LangGraph.

Key engineering challenges. Data quality, scoring discipline, outreach personalisation that does not feel generic, and avoiding overconfident enrichment when data is sparse.

Evaluation strategy. Curate a set of target profiles with known-good and known-bad matches. Score precision and recall on company identification. For outreach drafts, use LLM-as-judge on personalisation depth, but supplement with human review for any project you publish.

Write-up emphasis. Be honest about data limitations. Discuss the ethical considerations of scraping and outreach. The strongest portfolio pieces show that you have thought through the responsibility dimensions.

A note. Be careful what you publish publicly. Aggressive outreach automation can put you on the wrong side of platform terms of service. Build the project carefully and demonstrate restraint in the write-up.

What it is. A system in which multiple agents take different positions on a question, debate, and produce a synthesised conclusion. Useful for decisions where multiple perspectives matter, such as design reviews or investment analyses.

Why it is worth building. It is one of the few portfolio projects that meaningfully exercises multi-agent coordination, role design and adversarial evaluation. Most other projects can be done with single agents; this one cannot.

Suggested tech stack. AutoGen or CrewAI for the multi-agent orchestration. Roles for proponent, critic, judge and synthesiser. A structured output format for the debate transcript and final conclusion. Tracing for every turn.

Key engineering challenges. Preventing role collapse, ensuring genuine disagreement, controlling debate length, and producing useful synthesis rather than mush.

Evaluation strategy. Curate 20 decision questions with multiple valid perspectives. Score the system on argument quality, balance, synthesis usefulness, and decisiveness. Compare against a single-agent baseline; if multi-agent is not meaningfully better, say so honestly.

Write-up emphasis. Lead with the question of when multi-agent is justified. The strongest portfolio version of this project is brutally honest about the cases where it does not improve outcomes.

If your multi-agent debate system does not outperform a single agent on at least one well-defined metric, do not ship it. Showing thoughtful negative results is also impressive, but only if you are explicit about it.

A nuanced write-up here can stand out more than a positive result on a less rigorous project.

A great project with a poor write-up is invisible. The template I recommend, refined from reviewing dozens of portfolios.

Title and one-line description. Concrete and specific. “Deep research agent that produces cited reports” beats “An AI research assistant”.

Problem statement. Why did you build this? What is the user need?

Approach. A short architecture diagram and 200-300 words on the key design choices. This is the most-read part of any write-up.

Trade-offs. What did you choose against, and why? This single section signals engineering maturity more than any other.

Evaluation. Your eval setup, metrics, and results. Include numbers, not adjectives.

What did not work. Honest reflection on failures and dead ends. Counterintuitively, this section often impresses reviewers most.

What I would do next. Demonstrates ongoing engagement and product instinct.

Reproduction instructions. Make it easy to run. Include a sample command and expected output.

The full write-up should be 1,500 to 3,000 words. Anything shorter looks superficial; anything longer is rarely read.

A few patterns that consistently help.

Pin three to five repositories. Curate. Hiding weaker work is fine.

Each pinned repository has a strong README. The README is the project. Treat it as the primary artefact, not the code.

Include screenshots or trace snippets. A picture of a working trace tells a story that code cannot.

Tag releases. A repository with v0.1, v0.2 and v1.0 looks deliberate. An unmarked main branch looks experimental.

Keep commits clean towards the end of the project. Reviewers will scan recent commits. A final week of “fix typo” commits signals lack of polish.

Add a LICENSE. MIT or Apache 2.0 is fine. No LICENSE is a small warning sign.

Add a “How to Run” section at the top of every README. Make reproduction obvious.

For each pinned project, I recommend a clear directory structure with separate folders for the agent code, the eval suite, the documentation and any demo UI. Top-level clutter signals disorganisation.

A 2-3 minute demo video, embedded in the README, often shifts a reviewer’s impression of a project meaningfully upward.

The structure I use:

• 15 seconds: introduce the problem
• 30 seconds: show the architecture diagram with voice-over
• 75 seconds: live demo of the agent working on a representative input
• 30 seconds: highlight one trace or eval result
• 15 seconds: close with what you would build next

Record with a screen capture tool and a decent microphone. Audio quality matters more than video quality. Keep the demo focused on a single representative use case rather than trying to cover everything.

Loom, OBS or QuickTime are all fine. Upload to YouTube unlisted, or embed directly in the README via an animated GIF for short clips.

A good demo video signals product instinct. Hiring managers notice.

Mistakes I see consistently in candidate portfolios.

Too many half-finished projects. Three polished projects beat ten unfinished ones.

No evaluation. A project without any quality measurement is hard to defend in interviews.

Marketing-flavoured READMEs. Avoid superlatives. Engineers read superlatives as signs of weak content.

Mismatched scope. A project framed as “production-ready” that breaks on the first reproduction attempt damages credibility.

Missing traces. Agent projects without trace logs feel hollow. Include screenshots or examples.

Hidden code. A repository named “ai-agent” with no README inside is invisible. Make every project legible.

Generic problem statements. Pick a real, specific problem. Generic ones look like exercises.

Old projects without context. A 2023 project displayed without explanation looks like outdated work. Either refresh it or remove it.

A portfolio is curated. Treat every visible project as an active recommendation of your craft.

The discipline of removing work that no longer represents you is as important as the work of adding new pieces.

Realistic time and cost estimates for the projects, based on building them part-time while working full-time.

Costs assume you use a mix of mid-tier models for development and a smaller model for evaluation runs. Be disciplined about caching during development to control costs.

If you are on a tight budget, optimise by using local models for development iterations and reserving paid API calls for final evaluation runs.

If you are starting from scratch, my recommended sequence.

Project 1: Customer Support Agent. Smallest scope, fastest to ship, exercises RAG and tool use. A good warm-up.

Project 2: Deep Research Agent. Builds on the first by adding planning and longer-horizon execution.

Project 3: Coding Assistant or Lead Gen Agent. Pick the one most relevant to your target role. Coding for AI tooling companies, lead gen for sales and growth contexts.

Project 4 (optional): Multi-Agent Debate. Only if you are targeting senior roles or research-adjacent positions. Demonstrates more advanced patterns.

Spacing the projects six to eight weeks apart gives you time to ship each one to a high standard. Better to have two excellent projects than four mediocre ones.

Throughout, document your work publicly. Twitter or LinkedIn threads on what you learned, blog posts on specific patterns, contributions to relevant open-source projects, all multiply the value of the projects themselves.

A built project that nobody sees is half the value. Distribution patterns that work.

Publish a blog post for each project. The blog post is the write-up extended for a public audience. Cross-link to the GitHub repository.

Tweet a thread when you ship. Include a short demo GIF, the headline result and a link to the write-up. Tag relevant accounts (without being spammy).

Submit to Hacker News or relevant subreddits with discretion. Useful for one or two projects, not five.

Speak at meetups. A 15-minute talk on one of your projects, especially the trade-offs, is one of the highest-leverage career moves available to early agent engineers.

Engage with the community. Comment thoughtfully on others’ work. Reply to questions on Discord or forums. The reputation accrues.

Visibility is a multiplier. The same project, presented well, can yield 10x more career impact.