Notes from building multi-agent research and decision-support workflows — what actually matters when you move from a chat prompt to something that takes steps on your behalf, and where governance belongs in that process.
An AI agent is not a smarter chatbot. It is a model that has been handed a goal, a set of tools it may call, and permission to keep going until the goal is met. Everything difficult about agents lives in those last two clauses: which tools, and how far.
The guide below is the sequence I follow. It is deliberately stack-agnostic — the same six steps hold whether you orchestrate with an off-the-shelf framework or hand-roll the loop yourself.
An agent earns its keep when a task is repetitive, multi-step, and judgement-light. Write the task down as a sentence a colleague could follow — "find grant calls open to Nigerian SMEs this month, check eligibility, and draft a shortlist" — before you write any code. If you cannot describe the finished output, the agent cannot either.
An agent is a model plus tools plus a loop. Tools are ordinary functions with clear names, typed inputs, and honest error messages: search, fetch a page, read a file, write a row. Three well-described tools beat fifteen vague ones, because every tool description competes for the model's attention.
The core loop is: send the goal and available tools to the model, read back the tool it wants to call, run that call yourself, append the result, repeat until it returns a final answer. Cap the number of iterations and the total token spend from the first version — an uncapped loop is how a demo becomes an invoice.
Most agents need two kinds: a short scratchpad of the current run, and a durable store of facts worth keeping between runs. Reach for retrieval over a growing context window — summarise the run at the end and keep the summary, not the transcript.
Reading is cheap to get wrong; writing is not. Let the agent research, draft, and propose freely, then require a human confirmation before it sends an email, moves money, or publishes anything. In practice this single boundary removes most of the risk without slowing the useful part down.
Store every prompt, tool call, and result. Build a set of ten to twenty real tasks with known-good outputs and re-run them whenever you change a prompt or model — that is the difference between an agent you can improve and one you merely hope about.
Most of the safeguards regulators ask for are the same ones that make an agent work: a written scope, an audit trail, a named human accountable for consequential actions, and evidence that the system was tested before it was trusted. Building agents hands-on is what keeps my policy work honest — it is much harder to write vague rules about a system you have had to debug.