Agent design
Deciding what should be an agent at all. Deterministic workflows are cheaper and more reliable; agents earn their place only when the sequence of steps genuinely varies.
AI & Automation
AI agents & workflow automation
An agent is a model given tools and a goal, allowed to decide the steps. That is powerful for tasks with a variable path, triaging an inbox, reconciling records across two systems, researching and drafting, and it is genuinely risky if the tools can change data and the loop has no ceiling.
So I build agents with the boring parts attached: an iteration limit, a spend limit, permission scoping on every tool, a full log of what was called with what arguments, and an approval gate before anything irreversible. Those constraints are what make an agent deployable rather than a demo.
How I work on it
Process
Adjusted to the job, but this is the shape it usually takes.
-
Map the manual process
Watch how the task is done today, including the exceptions. The exceptions are where automation usually breaks.
-
Automate the deterministic parts first
Often 80% of a workflow needs no model at all. Doing that first shrinks the problem and the running cost.
-
Add judgement steps carefully
AI is introduced where a decision genuinely needs it, with its own evaluation and a confidence threshold.
-
Run shadowed before live
The agent proposes and a person approves for an agreed period. Autonomy is earned from an observed track record, not granted on day one.
Questions
Things people ask
Tasks that are repetitive but not identical, where a person currently reads something, makes a judgement call and updates a system. Support triage, document review, data reconciliation and first-draft writing all fit. Anything requiring perfect accuracy on every single item does not, unless a human checks the output.
Permissions, primarily. Tools are scoped so the agent literally cannot perform the dangerous action, read-only database credentials, no delete endpoints, an approval gate before sending anything external. Prompt instructions are a supplement to that, never the mechanism.
Hard caps per run and per day, enforced in code rather than watched on a dashboard. Combined with caching, smaller models for the simple steps, and alerting when a run exceeds its expected token budget.