Automate revenue with agentic AI, not another dashboard nobody opens.

About

An agentic AI engineer who builds where revenue and code meet

I build the software and the agents that run on top of it. That means full-stack product work, CRM and GTM automation, the cloud infrastructure underneath — and, on the research side, quantitative finance.

Real-world execution

A demo runs on data someone cleaned first. Production runs on duplicate accounts, half-filled fields, and a rep who typed the deal name three different ways. I build for the second one — which mostly means deciding what the system does when it is not confident, rather than assuming it always will be.

• Production data
• Failure modes
• Guardrails

In practice: the first week goes on the data nobody wants to look at — duplicates, half-filled fields, three spellings of the same account.

Revenue-aware engineering

Shipping a feature and moving a number are different jobs. Automation that saves twelve hours a week is worth nothing if those hours were never the constraint, so I start from the metric the team is actually judged on — pipeline, conversion, cost per outcome — and work backwards to what the software has to do.

• Pipeline
• Conversion
• Cost per outcome

In practice: the metric is agreed before the build starts, so there is something to check against when it ships.

Agentic architecture

Agents, workflow automation, CRM integration, agent-FTE systems, and the cloud delivery underneath them. The hard part is almost never the model — it is the boundary: which decision the agent owns outright, which one it escalates, and what it is allowed to touch while nobody is watching.

• Agents
• Orchestration
• CRM integration

In practice: every tool call an agent can make is written down first, along with what happens when it fails.

Research alignment

I am working toward a PhD alongside the day job, in AI and quantitative finance. The research reading changes how I build: it is where the habit of stating a hypothesis before running the experiment comes from, which turns out to matter more in production than it does on paper. Open to labs, supervisors, and collaborations.

• Quantitative finance
• AI research
• Publications

In practice: a claim gets a source or it gets cut — the same rule I apply to the writing on this site.

Team and founder leverage

Most of the leverage in a small team is not in the code. It is in whether the next engineer can read the decision you made six months ago and know why. Hiring input, code review habits, architecture reviews, and the occasional blunt second opinion for a founder about to commit to an expensive bet.

• Code review
• Architecture reviews
• Hiring input

In practice: the handover is the deliverable. If the team cannot run it without me, it is not finished.

Evidence before scale

An agent that nobody measured is a rumour. I set the success and escalation criteria before rollout, so there is a real answer to whether it worked rather than an argument about it six weeks later.

• Success criteria
• Escalation
• Measurement

In practice: success and escalation criteria are set before rollout, so week six is a review rather than an argument.

Public technical credibility

Eight published packages, twenty-odd technical write-ups, and profiles that update themselves. None of it is self-promotion for its own sake — it exists so that anyone deciding whether to work with me can check the work first and arrive at the conversation already knowing the answer.

• Open source
• Technical writing
• Public profiles

In practice: eight published packages and twenty-odd write-ups, all of them checkable without taking my word for it.