Custom Agent Building
In development. Taking enquiries.
- ·The unit of work is one agent with a defined job, the tools it may call, and the boundary it may not cross.
- ·Admission is by a written standard rather than by enthusiasm, because an agent nobody dispatches is a cost with no return.
| Becomes live when | One client shaped agent is published with its golden task and the evidence from running it, so a stranger can read what it was asked and what it actually did. |
| Built with | Claude API · TypeScript · Node.js |
| Delivered by | prompt-engineer · agentic-director |
| Skills used | agent-forge · skill-creator |
What this involves
The unit of work is one agent with a defined job: the tools it may call, the data it may see, and the boundary it may not cross. That is a smaller and more boring thing than most agent projects start with, and it is the reason the finished one gets used.
Admission is by a written standard rather than by enthusiasm. Every agent has to name what it consumes, what it produces, and which existing agent it would overlap with, because the common failure mode in an agent roster is not a bad agent, it is a third agent that does what two others already did.
There is no client-shaped agent published here yet, so nothing on this page is a receipt. What can be shown instead is the standard itself and the ecosystem it governs, which is public and openable, and the audit of it that found a third of its own members had never been dispatched.
How the work runs
1. Discovery
We agree what the project has to achieve, what it must not break, and how we will both know it worked, before any code is written.
2. Build
The work is built with an AI agent as the working partner and a human reviewing every change before it lands. You get commits you can read rather than a status update.
3. Review
You review running software at each milestone, not a screenshot of it, and the next milestone absorbs what you send back.
4. Launch
We deploy to production with checks in the pipeline and alerting that reaches a human, and you hold the repository and the infrastructure accounts.
Questions people actually ask
What separates an agent from a prompt with tools attached?
A boundary and an owner. An agent has a job it is accountable for, a fixed set of tools, and a written task that decides whether it is doing that job. A prompt with tools attached has none of those, which is why it works in a demonstration and drifts in production.
How would I know the agent works before trusting it with real work?
By running the golden task, which is agreed before the agent is built rather than written afterwards to match what it does. It is a small set of inputs with the outcome each one should produce, and it is run again on every prompt, tool or model change. Without one, there is no way to tell an improvement from a regression.
Why is this listed as having no sample when the site is full of agents?
Because the agents on this site are the ecosystem that built the site, not an agent built to a client's brief, and the two are not the same claim. The condition for this service becoming a proven one is stated on the page above: a client-shaped agent published with its golden task and the evidence from running it.