Key takeaways
- Choose projects that prove different capabilities: grounded knowledge, action with tools and multi-step operations.
- Show the business boundary, input/output contracts, permissions, success criteria and failure paths.
- Evaluate the final system state as well as the agent’s words and tool calls.
- Use synthetic or authorised data; never place customer credentials or personal data in a public portfolio.
- Two deep, runnable projects are more persuasive than seven shallow demos.
What should every AI agent portfolio project contain?
A reviewer should be able to answer six questions quickly: What problem does it solve? Why does it need an agent? Which data and tools can it use? What may it never do alone? How was it tested? What happens after failure?
Anthropic’s current eval guidance separates the trace - the sequence of model and tool interactions - from the outcome in the environment. That distinction matters. An agent may claim that it updated a record while the database stayed unchanged, or produce polished text after using the wrong source. Your portfolio should show both.
The anatomy of a credible project
Six evidence blocks
Seven portfolio projects, from focused to system-level
The seven projects below cover different capabilities, from grounded knowledge and document handling to operational routing and connected multi-workflow systems.
1. Grounded customer knowledge agent
RAGcitationshuman handoffBuild: an agent that answers policy or product questions from an approved document set, cites the exact source and creates a review ticket when evidence is missing or contradictory.
Proves: ingestion, metadata, retrieval, permission filtering, source attribution, abstention and escalation.
Test: supported question, no-answer question, stale document, conflicting sources, unauthorised document and prompt injection inside a retrieved file. Success means supported answers cite the correct source; unsupported or restricted cases do not produce a confident answer.
2. Document intake and validation agent
structured outputvalidationprivacyBuild: accept a document, extract a defined schema, validate required fields and route uncertain or inconsistent records to a person. Use synthetic forms rather than real identity documents in a public demo.
Proves: multimodal extraction, schemas, confidence policy, deterministic validation, secure storage and audit history.
Test: complete file, missing page, unreadable field, contradictory values, wrong document type and duplicate submission. The agent must never invent a missing value.
3. Lead research and qualification assistant
APIsCRMapprovalBuild: enrich a business enquiry from allowed public sources, map it to transparent fit criteria, prepare a short brief and draft a follow-up for human approval. Do not automate eligibility decisions in housing, lending, hiring or other consequential domains.
Proves: web/API research, provenance, CRM integration, deterministic rules, duplicate prevention and external-message approval.
Test: insufficient evidence, conflicting company data, existing CRM record, prohibited attribute and rejected approval. Success is a sourced brief and correct route, not a fabricated score.
4. Proposal writer with independent QA
documentssecond-pass QAversioningBuild: turn an approved scope and rate card into a proposal draft, then run a separate QA step for unsupported claims, missing requirements, arithmetic and format before a person approves export.
Proves: document generation, controlled source use, separation of drafting and checking, version history and approval.
Test: absent price, contradictory scope, unsupported case study, calculation error and outdated template. A failed QA check must block the final document.
5. Metrics monitoring and anomaly triage agent
scheduled workflowalertsevidenceBuild: collect approved metrics on a schedule, apply deterministic checks, ask the model to summarise context and send an evidence-linked alert to the owner. The agent may explain an anomaly but should not autonomously change budgets or systems.
Proves: schedules, data normalisation, thresholds, anomaly context, notifications, deduplication and incident records.
Test: missing source, delayed data, one-off spike, repeated alert, timezone boundary and normal day. Success means the right owner receives one actionable alert with source values.
6. Operations request router with SLA control
routingstaterecoveryBuild: classify incoming internal requests, request missing fields, route to the correct queue, track status and escalate before an SLA breach. Keep policy and access decisions deterministic.
Proves: state machine design, tool selection, clarification, queues, timers, handoffs, idempotency and recovery.
Test: ambiguous request, unsupported category, tool timeout, duplicate webhook, owner unavailable and resumed run. The workflow must preserve one authoritative request record.
7. Virtual AI Department capstone
multi-workflowshared dataobservabilityBuild: connect three focused workflows around one fictional company and shared data layer - for example lead intake, knowledge support and reporting. Use event routing and clear ownership rather than making every component a free-roaming agent.
Proves: system architecture, shared schemas, orchestration, cross-workflow permissions, approvals, audit logs, monitoring and change control.
Test: concurrent events, stale knowledge, partial outage, denied approval, schema change, replay and cost limit. Success means one component can fail without corrupting the rest of the system.
Which projects should you choose?
| Your target | Best pair | Optional third project | What the set proves |
|---|---|---|---|
| AI Automation Specialist / n8n Specialist | Document intake + operations router | Metrics monitoring | Reliable workflows, data, integrations and recovery |
| AI Assistant / RAG Builder | Knowledge agent + proposal QA | Document intake | Grounding, citations, structured output and review |
| Junior AI Implementation Specialist | Knowledge agent + lead assistant | Virtual AI Department | Requirements, tools, controls and system integration |
| Automation consultant | Operations router + metrics monitoring | Virtual AI Department | Process discovery, measurable operation and handoff |
| Code-first agent engineer | Knowledge agent + operations router | Rebuild one with an SDK and deployed service | Agent logic plus software engineering depth |
How to build a portfolio project step by step
- Write the one-page brief. Name the user, current process, allowed inputs, desired output, baseline and measurable success.
- Set the business boundary. List what the system may read, draft or change and what always needs a person.
- Draw the architecture. Show deterministic workflow, model decisions, tools, state, knowledge and system of record.
- Define contracts. Document input/output schemas, tool arguments, errors and approval payloads.
- Create the eval set before polishing. Include normal, edge, adversarial and recovery cases with expected outcomes.
- Instrument the run. Capture safe traces, tool calls, state changes, latency and cost without exposing secrets.
- Run a failure drill. Break a dependency, deny an approval or replay an event; document recovery and any fix.
- Package the evidence. Publish a clear README, architecture figure, short demo, test report, sample traces, limits and runbook.
The portfolio acceptance checklist
- The project solves a named user problem and explains why an agent is justified.
- All data is synthetic, public or explicitly authorised; secrets are excluded.
- Inputs, outputs, tools, permissions and the system of record are documented.
- Consequential or irreversible actions require policy checks or human approval.
- The eval set contains expected outcomes, not only example prompts.
- Evidence includes traces and final environment state.
- Error, escalation, retry and duplicate-event paths are tested.
- The README states known limits and what you would improve next.
What should the demo show?
Keep the main demo to two or three minutes: the problem, one normal run, one boundary or failure case and the resulting record or action. Then let a reviewer open the architecture, tests and runbook. Do not hide the implementation behind a polished video.
If a third-party integration cannot be shared, use a sandbox or recorded fixture and explain the substitution. Never share live API keys, customer data or a public endpoint that can perform costly actions.
Build a portfolio as a connected business system
Barcelona Code School’s AI Agent & Automation Bootcamp uses a fictional online school so students can build realistic workflows without exposing a real company’s data. The four-week / 160-hour programme connects n8n, Airtable, Supabase, RAG, approvals, QA, monitoring and multiple departmental workflows into a Virtual AI Department.
The programme is full-time, on campus in Barcelona or remote live, with no prior coding required. Tuition is €3,600. The outcome is a portfolio system and career preparation; employment is not guaranteed.
See the portfolio-focused BootcampFrequently asked questions
How many AI agent projects should be in a portfolio?
Two or three deep projects are usually more useful than many shallow demos. Choose projects that prove different capabilities, such as grounded knowledge, action through tools and multi-step operational control.
What makes an AI agent project portfolio-ready?
It needs a clear problem, architecture, real or sandboxed tools, documented schemas, permissions, approvals, representative evals, traces, final-state checks, failure recovery, limits and a runnable or recorded demo.
Can I use no-code tools for an AI agent portfolio?
Yes, if the project demonstrates system design, data contracts, integrations, control, testing and operations. Explain the underlying logic and failure paths. Code-first vacancies may still require Python, TypeScript and software deployment evidence.
Should I publish the source code?
Publish code or workflow exports when safe and licensed to do so, but remove secrets and private data. If full source cannot be shared, provide architecture, schemas, test results, selected traces and a clear demo of the outcome.
What data should I use?
Use synthetic data, public datasets with suitable licences or data you have explicit permission to use. Do not put customer records, identity documents, access tokens or confidential company information in a public portfolio.
Do portfolio projects guarantee an AI job?
No. Projects provide evidence of skills and judgement, but hiring also depends on prior experience, role requirements, communication and the market. Tailor the evidence to the responsibilities in each vacancy.