CUSTOM AI AGENTS
One agent, a short tool list, and a hard stop when it is unsure.
A copilot is not a chatbot bolted onto your website. It is one process with a job description: a system prompt that states what it owns, a short list of tools it may call, and a refusal path for everything else. I build those in Python on Claude, with every run logged so you can read back what the agent saw and why it chose the tool it chose.
The thing that kills agents in production is tool sprawl. Give one agent fourteen tools and it will pick the wrong one roughly as often as a bored intern would. So tools get scoped per role, arguments get validated before they execute, and anything irreversible — sending, deleting, paying out — stops at a human. I would rather an agent ask than guess.
Grounding is keyword search over your own files — BM25 over a folder of documents, not a magic index I cannot explain to you. It is cheap, it is debuggable, and when the agent quotes something you can find the line it came from. Each agent ships with a token ceiling per run, so a retry loop costs you a few rupees instead of a weekend of API bills.
WHAT I DO
- Agent spec — the one job it owns, the tools it may call, and the cases where it must refuse and hand back to a person
- Python agent code running on your stack, with the system prompt kept in a file your team can read and edit
- Role-scoped tool definitions with argument validation, so a malformed call fails loudly instead of doing something odd quietly
- Human approval gate on every irreversible action — sends, deletes, writes to a live record
- Run logs — every prompt, tool call and response stored, so a bad answer can be traced rather than guessed at
- Token and retry ceilings per run, plus a monthly cost estimate measured from test runs before anything is built
- Grounding over your own documents with BM25 keyword search, quoting the source line back inside the answer
HOW I WORK
- 01
SCOPE
I write down the single job the agent owns and the three things it must never do, before any code exists.
- 02
TOOLS
I define each tool it can call, validate the arguments, and decide which calls have to stop for a person.
- 03
HARDEN
I run it against your real messy inputs and edge cases, tightening the prompt until the remaining failures are boring ones.
- 04
DEPLOY
It goes onto your VM and your accounts with your keys, and you get the runbook, the logs and the cost ceiling.
BEST FOR
- A repeated judgement call one person makes twenty times a day from the same few documents
- Teams who already tried a generic chatbot and got vague, uncitable answers
- Work where the answer must be traceable — a quote, a source file, a log line
- Situations where a 90% correct draft reviewed by a person beats a slow perfect one
NOT THIS
- Not multi-agent architecture. If the job needs several agents handing work to each other, that is workflow design and it has its own page
- Not a model trained on your data. I use models as they ship; the customisation is prompt, tools and guardrails, and nothing touches the weights
- Not a public widget answering strangers on your marketing site. These are internal copilots with access to real systems, and they stay behind a login
THE PROOF
Published case studies from ai orchestration work. Each one names the client and shows what was delivered.
STRAIGHT ANSWERS
REST OF AI ORCHESTRATION
MAKE A
WISH.
Tell me what you're building. I'll tell you how loud it can get.
- /01
YOU WRITE
Tell me what you're building and what's in the way. Two lines is enough.
- /02
WE TALK
A 30-minute call, booked within 7 days. Real questions, no pitch theatre.
- /03
YOU GET A PLAN
Scope, timeline and an honest number, usually within a week.