Weekend Agent v2 — the build.

The first version of Weekend Agent took me a Saturday. The second took two.

The difference between v1 and v2 is small but important: v1 was a script that worked. v2 is a scaffold that survives the second person who clones it. The kind of repo where you can git clone, change a config file, and have an agent running on a cron within four hours — without needing to know how the inner loop is wired.

That distinction — script vs scaffold — turns out to matter way more than the actual agent inside.

What it does

The scaffold gives you:

• A scheduled job runner (cron + Modal)
• A Browserbase session pool with sane defaults
• A Claude Code harness with a tools/ directory you drop new skills into
• A typed config (agent.config.ts) that's the only file most people will ever edit
• Eval scaffolding baked in from day one — pnpm evals runs the suite locally; CI runs it on every PR
• A simple admin dashboard at /admin showing runs, costs, and failures

A new agent starts as a 60-line config file. Add new tools by dropping .ts files into tools/. The runtime auto-discovers them.

The five decisions that mattered

1. Cron-first, not chat-first. Most production agents I ship are scheduled, not conversational. v2 makes scheduled the default and conversational the opt-in.

2. Browserbase, not local Chrome. Headless Chrome on your laptop is a research tool. Browserbase is a production tool. The difference is reliability across model versions, which matters more than people expect.

3. Tools as files, not as code. I used to write tool definitions as JS objects inside the agent file. v2 puts every tool in its own .ts file with a default export. Diffing a tool change becomes trivial. Reviewing PRs becomes pleasant.

4. Evals from minute one. The init script creates an evals/ directory with one passing case and one failing case, so you immediately have a habit of adding to it instead of writing the suite later (you won't).

5. Dashboards over logs. Even for one-person projects. The cost of a /admin page is small. The cost of debugging "what did the agent do yesterday morning" without one is huge.

What I'd change

The next version is going to do two things differently:

• Default to two models in rotation — Opus for hard steps, Haiku for everything else. The cost difference is large and the quality difference, when scoped right, is invisible.
• Treat skills as installable packages — pull from a registry instead of putting them in tools/. This is going to require some convention work, but I think the ergonomics are worth it.

The repo is open. Fork it, change agent.config.ts, set your env vars, and run pnpm dev. If you ship something with it I'd love to hear about it.