Weekend Projects: Safer Agents + Practical Automation

This week we kept circling the same point: agents are only useful when they’re safe, cheap, and predictable. Monday was about open models getting easier to run. Wednesday was about token efficiency and the unglamorous plumbing that keeps an agent from wandering off. Now let’s turn that into three weekend builds you can actually ship.

Project 1 — A “sandbox-first” agent runner (local dev version)

• Time: 4–6 hours
• Tools: Docker, Python, and an LLM API of your choice

What you’ll build: A small agent harness that can read/write only inside a working folder, run a few approved commands, and log every tool call. Think of it like a lockbox for your agent. You want the model to do work, but you don’t want it free-ranging on your machine.

OpenAI just pushed its Agents SDK toward this idea by adding sandboxing so agents can operate in controlled environments, plus a harness designed to work with files and approved tools in a workspace (TechCrunch).

Build steps:

1. Create a Docker container with a single mounted folder like /work.
2. Write a tiny tool layer with explicit allow-lists:
   • read_file(path) — only under /work
   • write_file(path, content) — only under /work
   • run_cmd(cmd) — only allow commands like pytest, ruff, node, or a build script
3. Log every action to a JSONL file: timestamp, tool name, arguments, result length, and a short “outcome” string.
4. Give the agent one job: “Fix failing tests” or “refactor this script” in the mounted folder.

What you’ll learn: The real value in agent work isn’t the prompt. It’s the runtime contract: what the agent can touch, how it’s interrupted, and how you roll it back when it makes a mess.

Project 2 — The “Lead Follow-Up” autopilot (automation backbone + AI helper)

• Time: 3–5 hours
• Tools: n8n (self-hosted if you want), a form (Typeform/website form), Gmail/Outlook, and a spreadsheet or CRM

What you’ll build: A follow-up system that replies fast, captures clean job notes, and nags politely when a lead goes cold. This is where small shops bleed money: you did the marketing, the phone rang, and then nobody followed up.

n8n’s AI Agent node is made for this “uncertainty + tools” kind of workflow: let the model decide what to do next inside the workflow, instead of hardcoding every path (Synta).

Build steps:

1. Automation backbone: New lead form → create a row/card in your pipeline → send a “we got it” confirmation.
2. AI helper: Summarize the lead message into 5 fields: job type, location, urgency, timeline, constraints.
3. Follow-up ladder:
   • 48 hours no reply → send follow-up #1
   • 7 days no reply → send follow-up #2 + ask one simple qualifying question
   • 14 days no reply → close the loop (“Want me to keep this open?”)
4. Safety rail: if the AI can’t extract a phone/email, route to “needs human” instead of guessing.

What you’ll learn: The difference between AI and automation in the real world: automation moves the work; AI makes sense of messy inputs so the automation can keep moving.

Project 3 — A cost-and-latency meter for your prompts (stop paying twice)

• Time: 2–3 hours
• Tools: Any LLM API, a small script (Python/Node), and your real prompts

What you’ll build: A tiny dashboard that tracks token use per task, and highlights when you’re re-sending the same context again and again. If you’re building agents, this is the quiet killer: the agent reads the same wall of text every turn and you pay for it every time.

Build steps:

1. Wrap your LLM calls in a function that logs: model, prompt tokens, completion tokens, total cost estimate, and latency.
2. Tag each call with a task name (“lead_followup”, “quote_draft”, “invoice_reminder”).
3. Run three experiments:
   • Baseline: send full history every turn
   • Trimmed: send only the last message + a structured summary
   • Cached: keep static instructions in one place and reuse them (system prompt / reusable template)
4. Print a simple report: “Same outcome, 40% fewer tokens” (or whatever you find).

What you’ll learn: Context engineering in practice: you’re not trying to be clever — you’re trying to make the system cheap enough to run every day.

If you build one of these this weekend and want a second set of eyes, send me what you’ve got. The goal is always the same: fewer dropped balls, fewer surprises, and tools that keep working when you’re busy doing the real job.