I build AI that does your team’s tedious investigation work.
When something breaks or your cloud bill jumps, the agents I build work out why and post the answer in Slack — in minutes, not the afternoon it usually takes. They run inside your own systems, and can only read your data, never change anything.
Already doing this in production today at [[CURRENT_COMPANY_DESCRIPTOR — e.g. a multinational energy & fintech company]], unattended, for weeks at a time.
Daily cost threshold breached — Amazon EC2 at $154.06 vs threshold $120.00 (+$34.06 over)
RCA — Amazon EC2
Now: On-Demand 1,288h $124.91 | SP 267h $27.65
Root cause: On-demand usage dropped. The increase is Savings-Plan utilization, not runaway spend. Real driver: NAT egress up 230GB.
A real example: a cost alert comes in, and the bot replies in the same thread with what changed and why.
The problem
Finding out what went wrong eats your team's time.
Every alert starts the same way: someone digs through a pile of dashboards and logs to work out what changed — before they can even start fixing it. That first hour is the expensive part, and it repeats every time.
The surprise cloud bill
Your cloud bill crosses a limit and an alert fires. Someone spends 45 minutes digging through billing dashboards, only to find it was a routine billing shift — not a real problem or a mistake.
The 2 a.m. page
Something breaks in the middle of the night. Which change caused it? The obvious logs show nothing, so it takes an experienced engineer an hour of tracing to find the real cause.
The “what happened to this customer?” question
A product manager needs to know why a customer's order failed, so they interrupt an engineer to read the logs and query the database — a question that didn't really need an engineer.
How it works
Plain code gathers the facts. AI does the reasoning.
The same simple pattern handles a cost alert or a system outage: ordinary code collects the evidence, and the AI only weighs in where judgment actually helps. That mix is what makes it cheap to run and reliable enough to leave alone.
Two paths, on purpose
Predictable problems — a cost alert always needs the same information — get a fixed, step-by-step process with one AI call at the end. It's cheaper and more dependable. Open-ended problems get a smarter agent that picks the right playbook for the situation.
“Because cost RCA always pulls the same shape of data, a deterministic pipeline plus a single LLM analysis call is cheaper and more reliable. Infra RCA is open-ended, so it gets the full agent with a skill router.”— from my runbooks
It learns from every mistake
What the system knows lives in plain written playbooks — which alerts matter, which to ignore, where to look. Every time it gets something wrong and I fix it, that lesson gets written down, so it's never made again.
“The knowledge compounds.”— from my runbooks
It can only look, never touch
The system is given permission to read your data and nothing else — no ability to change, delete, or move anything. Under the hood that's cloud access scoped to Describe / Get / List only. That's what makes it safe to run without someone watching.
What I build
The kind of work I take off your team's plate.
Different problems, one idea: point AI at the slow, repetitive, judgment-heavy work — and let your people focus on the rest. A few of the things I build:
Investigate incidents and alerts
- What it is
- An agent that looks into a system alert on its own and posts the likely cause, with evidence, in your team's chat.
- Who it's for
- Teams buried under manual alert triage and on-call toil.
- What you get
- Faster answers, fewer 2 a.m. wake-ups, and knowledge that no longer lives in one person's head.
Explain cloud-cost spikes
- What it is
- An agent that turns a cost alert into a plain explanation of what changed and whether it's actually a problem.
- Who it's for
- Teams whose cloud bill jumps with no quick answer.
- What you get
- The cause in minutes instead of a senior engineer's lost afternoon.
Self-serve answers for your team
- What it is
- An assistant that lets non-engineers ask questions of your logs, database, and code — read-only, in plain language.
- Who it's for
- Product and support teams who keep interrupting engineers to look things up.
- What you get
- Answers without pulling an engineer off their work.
Set up AI safely inside your systems
- What it is
- Get AI tools deployed inside your own infrastructure the right way, plus training so your team can run and extend it.
- Who it's for
- Teams told to “adopt AI” with no safe path to production.
- What you get
- A safe, reviewable setup and a team that isn't dependent on me.
Automate repetitive workflows
- What it is
- Connect the tools you already use so routine, manual steps happen on their own.
- Who it's for
- Teams doing the same manual busywork between systems every week.
- What you get
- Documented automations with a clear trigger, steps, and result.
Proof
Three examples, out of many, running in production.
A closer look at three of the systems I've shipped — each running on its own for weeks, safely and unattended. They're a sample of the work, not the whole of it; the same approach fits most of the repetitive, judgment-heavy tasks your team handles.
More work
A few other things I've built.
Other systems I've designed and shipped end to end, on my own. Tap any card for detail.
Self-serve debugging for product teams
An internal assistant that lets PMs answer 'what happened to this customer or order?' without pinging engineers. It queries the database (read-only), the logging service, and the codebase, and answers in plain language.
[[DETAILS: stack, data sources, guardrails, usage numbers]] · [[SCREENSHOT]]
Portfolio intelligence assistant
Consolidates investment holdings across multiple accounts into one place and answers natural-language questions ('have I tax-harvested this position?'). Built end-to-end solo, AI-assisted.
[[DETAILS + SCREENSHOT]]
Workflow automation
Automations built on n8n and Zapier — connecting Google Sheets, internal APIs, and agents; BI reporting with Looker.
[[2–3 CONCRETE EXAMPLES: trigger → steps → outcome]]
Agent skills & enablement
Authoring the skills layer for agent platforms: how to structure runbooks the model actually follows, how to test them, and how to make knowledge compound. I maintain a curated library of 80+ skills across 18 categories with usage tracking and automated curation.
Multi-agent orchestration
A Kanban-backed orchestrator/worker system for routing decomposed work to specialist agents with dependency gating, heartbeats, structured handoffs, and hallucination guardrails — workers can only claim task IDs returned by real API calls. Design rule: “Cheap to ask; expensive to spawn the wrong fleet.”
Client website builds
Static, fast, accessible marketing and portfolio sites built to the same engineering standard as everything else here.
[[LIST 1–3 CLIENT SITES WITH PERMISSION, OR CUT THIS CARD]]
How we'd work together
Start small and fixed. No big commitment up front.
We begin with a short, fixed-price look at where AI would actually help you. Then I build one thing, end to end, with clear goals agreed before I start.
Look & plan
I learn how your team works, find the one thing where AI would save the most time, and hand you a concrete plan — including exactly what access it would need. [[PRICE_RANGE_OR_CUT]]
Build the first one
I build one thing, end to end, running inside your own systems — with tests, monitoring, and clear documentation. We agree what success looks like before I start.
Grow & hand over
Add more over time, and set your team up to run and extend it without me. No lock-in — you own everything.
How I work
A few rules I don't break.
These aren't slogans — each one shows up as something concrete in the work above. It's how I keep these systems trustworthy enough to leave running.
- 01
Tell me what changed, not everything.
A good answer is what actually changed and why — not a wall of data you already knew. Short, and only the things that matter.
- 02
Read-only first.
The system earns the ability to change things last, if ever. It starts able only to look, and a human signs off on anything that could do harm.
- 03
Simple where it can be, smart where it must be.
Plain, predictable code for the predictable parts; AI only where real judgment is needed. And everything the system knows is written down and tested.
- 04
Silent when healthy.
Monitoring should say nothing when all is well and be specific when it isn't. Nobody reads the channel that cries wolf.
- 05
Proven, not promised.
Backups are tested by actually restoring them. Timeouts come from real incidents. If I claim something works, I can show you it working.
- 06
It gets smarter over time.
Every mistake gets fixed and written down, so it never happens twice. The system improves with each real incident — and your team stops re-learning the same lessons.
Safety & security
Your data and systems stay yours.
The first worry is always “I don't want AI touching our systems.” Good instinct. Here's exactly how I keep it safe — in plain terms, with the technical detail underneath for whoever needs it.
It can only read, never change
Access is limited to looking at data — no ability to edit or delete. The exact permissions are written down and reviewable before anything runs.
No passwords lying around
It uses short-lived, managed credentials instead of stored keys, kept locked down and read-only — never exposed in commands or logs.
It runs on your turf
Everything lives in your own environment and your own chat workspace. Nothing routes through a service of mine.
Only real requests get through
Incoming messages are cryptographically verified, de-duplicated, and rate-limited, so nothing can spoof or spam it.
A human approves anything risky
If something ever needs to change state, the system proposes the exact action and waits for a person to approve it. Nothing destructive happens on its own.
It sees only what it needs
It reads system data like metrics, costs, and logs — scoped narrowly. Access to any customer data is opt-in and limited.
[[REVIEW: adjust data-access claims to what you're comfortable claiming]]
Tech stack
The tools behind the estate.
Chips marked as placeholders are pending confirmation.
AI / agents
Cloud & infra
Observability
Backend
Automation & data
Collaboration
FAQ
The questions engineering leaders actually ask.
Does this run inside our own systems?
Yes — that's the only way I do it. It lives in your own environment and your own chat workspace. Nothing routes through a service of mine, and I never copy your data out.
What access does it need?
Only permission to read — never to change or delete. The exact access is written down so you can review it before anything runs, and anything that could change a system always waits for a person to approve it.
Will this work with our setup?
Almost certainly. If your alerts show up in a chat tool and your data is reachable by the usual monitoring tools or an API, it fits. The approach isn't tied to any one vendor — I build it around what you already use.
Does it replace engineers?
No. It takes over the slow first part of every investigation — the gathering and cross-checking — so your engineers start from the answer instead of a blank screen. The judgment calls stay with them.
What happens when it's wrong?
It always shows its evidence, so a wrong answer is obvious in seconds rather than trusted blindly. And every miss gets turned into a test and a fix, so the same mistake doesn't happen twice.
How long until something useful is live?
A scoped pilot typically ships in [[2–6 weeks — CONFIRM]]. The discovery phase gives you a fixed scope and success criteria before you commit to a build.
Can our team maintain it after you leave?
Yes — that's a design goal. Runbooks are Markdown, tests are plain Python, docs cover architecture, operations, and troubleshooting, and handover is part of the engagement.
Which models do you use? Can we use our own accounts?
Model-agnostic within reason, Claude-family primarily. It runs on your API accounts or subscription plans, so costs and data governance stay with you.
About
A backend engineer who applies AI to engineering operations.
I'm a backend engineer on a Data & Analytics team at [[CURRENT_COMPANY_DESCRIPTOR]], operating production AWS infrastructure [[TEAM/SCALE DETAILS — CONFIRM WHAT'S SHAREABLE]]. My credibility comes from building and operating real systems first, and applying AI second.
I run a self-hosted agent platform and home lab — the production estate in these case studies runs on infrastructure I administer end to end, from TLS certificates to IAM policies to the cron jobs that keep OAuth tokens alive. I build and ship complete products solo, AI-assisted.
Contact
Bring an alert channel you hate.
The first call is a technical conversation, not a sales pitch. We'll look at a real alert, and I'll tell you whether an agent is the right tool — and roughly what it would take.