I work directly with founders and small teams to design agentic workflows that take real work off the team, then build and hand them over. No engagement layers, no slide decks you have to translate into software.
Startups where a handful of people are doing work that does not scale: manually triaging inbound, copying data between tools, compiling the same report every week, researching accounts by hand, or answering the same internal questions over and over.
You do not need a platform rollout or a transformation programme. You need a small number of workflows that reliably do a job, wired into the systems you already use, that your team can run and change after I leave.
Concrete, repeatable workflows — the ones that usually pay for themselves first.
Inbound email, forms, or tickets get read, classified, enriched, routed, and drafted against — so a human starts from a decision instead of a blank inbox.
Agents that gather, read, and summarise sources against a brief — account research, competitor tracking, diligence prep — and cite what they used.
Recurring reports assembled from your own data on a schedule, with the commentary drafted and the anomalies flagged rather than buried.
Qualify, enrich, score, and route inbound leads, with a drafted first response that a human approves instead of writes.
The glue work between tools: reconciling records, chasing missing fields, updating systems of record, and escalating only the exceptions.
An agent grounded in your own documents and data that answers internal questions with sources, instead of a wiki nobody updates.
Short, sequential, and built to end with your team owning the result.
We map where time actually goes and which processes are rule-shaped enough to automate. You get a ranked shortlist with an honest note on what is not worth automating yet.
The highest-value workflow gets built against your real data, fast, so the decision to continue is made on something working rather than a proposal.
The workflow is wired into the tools you already use, with guardrails, evals, fallbacks, and human checkpoints where mistakes would be expensive.
Your team gets documentation and a working session on how it runs, how to change it, and how to tell when it is misbehaving.
Both approaches are legitimate. They solve different problems at different sizes.
| Independent (this) | Large consultancy | |
|---|---|---|
| Who does the work | The person you talk to is the person building it. | A partner scopes it; a delivery team builds it. |
| Best fit | Startups and small teams needing a few workflows working soon. | Large organisations needing change management across many teams. |
| Typical output | Running workflows integrated into your stack, plus handover. | Strategy, target operating model, and a staffed delivery programme. |
| Overhead | One contract, direct communication. | Procurement, account team, structured reporting. |
| After the engagement | Your team owns and edits it. | Often an ongoing managed relationship. |
Some processes are too unstable, too rare, or too high-stakes to hand to an agent, and some are better fixed by deleting a step than by automating it. Saying so is part of the audit — automating a broken process just makes it fail faster.
Engagements are scoped per project rather than sold off a price list, because a workflow touching two tools and a workflow touching nine are not the same job. The shape is usually an audit first, then a build phase, so you can stop after the audit if the answer is that automation is not worth it yet.
To scope it I need three things from you: a description of the process as it runs today, a rough idea of the systems involved, and one person who knows the process well enough to answer questions. That is normally enough for me to come back with scope, timing, and cost.
Everything else — terms, ownership, and handover — is agreed in writing before any work starts. Ask and I will walk you through exactly how I structure it.
A process where a model does more than answer a question: it plans a short sequence of steps, calls tools or APIs to gather and change data, checks the result, and escalates to a person when it is unsure. The useful ones are narrow and well-instrumented, not general-purpose assistants.
No. Most engagements start from a normal stack — email, a CRM, a spreadsheet or database, and a couple of SaaS tools. The work is connecting an agent to those safely, not replacing them.
Large firms are built for organisation-wide change programmes and staff them with a team. This is a single engineer working directly with your founders on a small number of workflows. If you need change management across hundreds of people, a firm is the better fit; if you need three workflows live and owned by your team, this is.
It is designed to. Workflows get guardrails, evals against known cases, logging, and human checkpoints on any step where a mistake is costly. The goal is a system that fails visibly and recoverably, not one that is assumed to be right.
Ownership and handover are agreed in writing before work begins, and the whole engagement is designed to end with your team able to run and change things without me. If you want the specifics of how I structure that, ask directly and I will explain it.
It depends far more on access than on build time. If the systems and sample data are available on day one, a first working version arrives quickly; if we spend three weeks waiting on credentials, it does not. Describe the workflow and I will give you a realistic range for yours rather than a marketing number.
Tell me the process that is eating your team’s week and what systems it touches. If it is a good fit I will say so, and if it is not I will tell you that too.
Get in touch →Got an idea, question, or just want to say hi?