AI agent development for work that actually ships
AI agent development is building software where a language model plans and takes actions – calling your APIs, updating records, opening tickets – rather than just answering questions. I build agents that do a specific job in production, with scoped permissions, evals, audit trails and a clear point where a human approves.
I also build for agents. Craaft is a kanban board where people and AI agents work the same cards, through MCP or a REST API, with the same permissions. That’s where most of my opinions about agents come from.
Who this is for
You have a repetitive, multi-step workflow that a person does today by reading something, deciding, and clicking through several systems: triaging inbound requests, reconciling records, preparing a case for review, keeping a project board current. You’ve tried a single prompt and it isn’t enough, because the work needs tools, state and judgement across several steps.
If the job is one step – summarize this, classify that – you don’t need an agent. That’s an ordinary AI integration, and it’s cheaper to build and easier to test.
How I build AI agents
- Start from the workflow, not the framework. I map the steps a person takes today, which ones need judgement, and which are deterministic. Deterministic steps stay as code. The model only handles the parts that need it.
- Small, well-named tools. An agent is only as good as its tools. Each one does one thing, validates its input, returns errors the model can act on, and is safe to retry. Ten precise tools beat one that takes free-form SQL.
- Least privilege. The agent acts as a scoped identity with only the permissions its job needs – not an admin token. In Craaft, an agent is a board member like anyone else: it can’t touch what it hasn’t been given.
- Human checkpoints for anything irreversible. Sending money, emailing customers, deleting data: the agent proposes, a person approves. Over time, as the evals prove out, some checkpoints can relax.
- Bounded loops. Step limits, token budgets and timeouts per run, so a confused agent stops and escalates instead of spinning.
- A full trace. Every plan, tool call, argument and result recorded, so you can answer “why did it do that?” and replay the failure in a test.
Security: the part most agent demos skip
Agents read untrusted content – emails, tickets, web pages, uploaded files – and that content can carry instructions. Prompt injection is not a solved problem, so I design as if it will happen. The dangerous combination is an agent that has access to private data, reads untrusted input, and can send data out. I break at least one leg of that triangle for every agent: restricting outbound actions, separating the agent that reads untrusted input from the one that holds privileges, or requiring approval before anything leaves the system.
The AI agent security guide covers the threat model in detail.
Evaluating agentic AI before it touches production
Agentic AI development fails quietly. An agent that is right 90% of the time on each step is wrong a lot more often across a ten-step task. So I build an eval harness alongside the agent: recorded scenarios with expected end states, graded on outcome (did the right records change?) rather than on the exact path. It runs in CI on every prompt, tool or model change.
Then the agent ships in shadow mode – proposing actions a human reviews – before it acts on its own. You get real accuracy numbers from your own traffic before you trust it.
Where agents live: your product and theirs
Two different projects often get called “building agents”. One is an agent inside your product that does work for your users. The other is making your product something other people’s agents can use – Claude, ChatGPT, Cursor or an in-house agent. The second is usually a custom MCP server plus a clean API, and it’s often the faster win.
For a wider view of patterns and when to use them, see agentic workflows and AI agents for business.
Why me rather than an AI agent development company
I’m an engineering lead with 20+ years in production and 200+ projects behind me, not a framework vendor. I don’t have a platform to sell you, so the agent gets built in your stack, with your team, using whatever orchestration is simplest – often plain code and a loop rather than a heavy framework. Everything is measured on ROI, not demos: if the agent doesn’t beat the current process on cost or time, we stop.
Questions
What is the difference between an AI agent and a chatbot?
A chatbot answers. An agent acts: it decides on steps, calls tools such as your APIs or database, observes the results and continues until a task is done. That makes agents more useful and riskier, so permissions, approval steps and evaluation matter far more.
Which agent framework do you use?
Whatever is simplest for the job. Many production agents are a loop around a model’s tool-calling API plus well-designed tools, and don’t need a framework. When orchestration, retries and state persistence get complex, I use a durable workflow engine or a framework your team can maintain.
How do you stop an agent doing something harmful?
Least-privilege credentials, narrow tools with validated inputs, step and budget limits, human approval for irreversible actions, and full traces. I also assume prompt injection will happen and limit what an agent can send out of the system.
How long does it take to build an AI agent?
A narrow agent for one workflow can reach shadow mode within the first two-week sprint. Getting it to act unsupervised depends on how much evidence the evals and shadow period produce, which is usually several more weeks.
Have a workflow you’d hand to an agent?
Walk me through it. In a two-week sprint we build a scoped agent against your systems, run it in shadow mode and see the real accuracy before deciding more.
GMT+2 · Full EU overlap · US East mornings