Why an agent-native portfolio?

Date: 2026-04-18 Post 1 of ~27 (build-in-public, 3x/week for 9 weeks)

Recruiters and hiring managers at AI companies increasingly run the same workflow as their engineers: connect an agent, let it research, skim the highlights. If the portfolio is a static site, the agent has to screen-scrape markdown and pray it parsed right.

So I'm building a portfolio that IS an MCP server. Connect your agent, call structured tools, get structured answers. The same handlers also power a CLI (npx @danielmicaletti/portfolio) and a web UI. Four interfaces, one handler.

The portfolio is the product demo. If the thesis of "harness engineer" means anything, it's that the scaffolding around the model matters — the tool choices, the data shape, the guardrails, the evals. Shipping a portfolio without those isn't demonstrating harness engineering, it's describing it.

This week

• Phase A (today/tomorrow): Turborepo monorepo, pre-commit sanitization gate, workspace scaffolding. Boring but load-bearing.
• Phase B (days 3-6): Real MCP server with 9 tools, the CLI, first HTTP endpoint.
• Phase C (days 6-7): Web scaffolding. Landing page shell.

What you can read while it's being built

• Full spec: docs/superpowers/specs/2026-04-16-agent-portfolio-design.md
• Expert review synthesis: docs/plans/spec-expert-review-2026-04-16.md
• Implementation plan: docs/plans/agent-portfolio-implementation-plan-2026-04-18.md
• Evals as they're written: docs/evals/cases/*.yaml (PRs welcome)

Watch the repo if you want to see how it's built. Fire up the CLI after Phase B (day ~6) if you want to test it against your own company.

— Daniel