AI agents and automation, built safely
Small AI tools and automations for real workflows, built with Claude Code and engineered so they can't send, spend, or delete anything without a person saying yes.
Why I can build these
I built my own first. My command-line assistant runs my tasks, calendar, and work pipeline every day, and it was built with Claude Code under the same rules I bring to clients. The numbers, the architecture, and the deploy process are on Built with Claude Code.
Safety by design
Companies are discovering that AI agents need guardrails. Every tool I build for you comes with these:
- You approve every action that leaves the system. Emails, payments, posts, and deletions wait for a person to confirm a single, specific target.
- Plain code wherever possible. Routine steps run as ordinary, predictable code; a model is called only for writing and judgment, which keeps running costs to pennies.
- Defense against prompt injection. Anything the tool reads from outside, such as an email or a web page, is handled as material to work on and never as a command to follow.
- Credentials kept out of the code repository, in your own secret store.
- Automated tests that run before every change ships, plus a quick check on the live system afterward.
- Encrypted backups with a restore you've watched work.
- The right model for the job, chosen by testing candidates on your real task rather than by brand.
What I build for clients
Focused tools with a clear job: a morning briefing assembled from your tasks, calendar, and inbox; triage of incoming requests into your project tool; a research assistant that gathers sources and drafts a reviewable summary; integrations between systems that don't talk to each other; command-line tools for repetitive website and data chores; and audits of AI output before anyone relies on it.
How a pilot works
Every build starts as a pilot, defined in writing before work begins:
- Inputs: what goes in, from where.
- Permissions: which accounts and data it touches, and nothing more.
- Outputs: what it produces, where it's saved, and how a person reviews it.
- Acceptance: the tests that prove it works, run in front of you.
- Handover: the code in your repository, documentation, ownership of every account, and what to do when it fails.
The questions I ask
What's the actual job? What happens after this step? Where is the result saved? Can you recover it if something goes wrong? What does this error mean? Does the system remember what it needs to remember? Those questions decide whether an AI tool saves time or creates a new mess.
Advice before building
Not every team needs a custom tool. Often the right first step is advice: which tasks are worth automating, which off-the-shelf tools fit, what your team's working practices should be, and what should never be pasted into a public AI service. That's available on its own as part of strategic advisory.
Common questions
Who owns what you build?
You do. Pilots run on your accounts, and the code, prompts, tests, and documentation are handed over at the end.
Do you build large AI applications?
I build small, focused tools that prove value quickly. When a pilot needs to grow into a larger system, I specify it and work with developers who build at that scale.
Tell me the workflow you'd automate
Updated October 5, 2026