Custom AI agent development, built around your exact workflow

Custom AI agent development starts where templates stop. The agent is engineered on your data and the model you choose, then wired into the systems the business already runs — CRM, inbox, internal tools, whatever the workflow touches. The output is not a general assistant; it is a system that knows your definitions, your exceptions and your approval rules.

The part that decides whether it survives contact with production is the unglamorous half: every action logged, access split by capability, and a human kept in the loop on anything consequential. Those are designed in at the start, because retrofitting an audit trail after an incident means reconstructing what happened without one.

How to scope a custom AI agent project

Scoping is where custom builds succeed or quietly fail, and the common mistake is to specify what the agent should do while leaving out what it must never do. A scope document that survives implementation answers six questions in order:

1. What starts a run? A schedule, an inbound webhook, a row appearing, a human asking. Name it precisely, because the trigger determines the failure mode — a cron job that stops is silent, while a webhook that fails is loud.

2. What may it read? The exact systems, the exact fields. "Access to the CRM" is not a scope; "the contact record, the deal stage and the last five activity entries" is. This list is also the one your privacy review will ask for, so writing it once serves twice.

3. What may it do unattended? The actions that execute without a human. Keep this list short at first and expand it from evidence — an agent that has drafted 200 correct replies has earned permission to send, and one that has not, has not.

4. What requires approval? Anything with an external consequence: money moving, a message to a customer, a record being deleted, a decision about a person. This is the gate, and it is a design element, not a training-wheels phase to remove later.

5. When must it stop? The refusal conditions — missing data, low confidence, an unexpected state, a rate limit, a dependency that has changed. An agent with no stop condition does not fail; it improvises, which is worse.

6. What is kept, and for how long? Run logs, memory, intermediate artefacts and outputs each need a retention period and a deletion path. Agents accumulate state faster than any manual process, and the retention rule is the only thing that bounds it.

Two sanity checks close the scope. First, the reversal test: for every unattended action, how is it undone, and by whom? Second, the silence test: if the agent stopped running tonight, how long before someone noticed? If the answer to the second is "next quarter", the workflow did not need an agent. Sizing the calendar around this scope is a separate exercise —what actually consumes time in a production agent buildbreaks that down stage by stage.

When custom is worth it — and when it is not

Custom is an investment, and it is the wrong call more often than a studio selling it would admit. It is worth it when:

• The workflow is high-volume. The task repeats constantly, so the time spent encoding its rules is recovered quickly.
• The workflow is consequential. Errors have financial, regulatory or reputational weight, so audit trails, scoped access and approval gates are requirements rather than nice-to-haves.
• The workflow is genuinely yours. It depends on your data, your rules and your systems, and no template covers more than the outline.
• Self-hosting is mandatory. The data cannot leave your infrastructure, which rules out platforms whose architecture assumes it can.

Custom is not worth it when:

• The task is fixed and never varies — a scheduled script is cheaper to build and far cheaper to debug.
• The volume is low enough that a person handles it in the gaps of their week without noticing.
• An existing product already covers the task cleanly — the no-code agent platform comparison is the honest place to check that before commissioning anything.
• What is actually wanted is a conversational interface over documents, which is a different product — the agent-versus-chatbot distinction matters most at exactly this decision point.

Drawing that line is part of the free blueprint, and a blueprint that ends in "do not build this" has done its job.

What the build itself looks like

1. Architecture from the scope. The six answers above become the design: data model, capability boundaries, integration points, and the gate positions. Nothing is written until this is agreed.

2. Model and fallback selection. The primary model for the task, plus a fallback chain, because provider entitlements change without notice. The model is a component; the system is designed so replacing it is configuration.

3. Integration engineering. Credentials scoped per capability, retries and idempotency where writes happen, and explicit handling for the partial-failure case that integration demos never show.

4. Guardrails and observability. Audit logging, approval gates, stop conditions and a health check that reads last-run state — because a scheduled job that never fires is the failure nobody sees until a quarter later.

5. Proof on real work. The agent runs against real data and real edge cases, in observe-only mode first where the actions are consequential, then with permission to act.

6. Handover. Units, configuration, runbooks and the scope document live in your environment. If you are evaluating who should do this work,the questions worth asking an agent developer before hiringare the ones we would expect to answer ourselves.

Custom, Hermes, or OpenClaw

Three shapes, chosen by what the workflow demands:

The short version: Hermes when one agent with memory is enough,OpenClaw when stages need separate authority, and custom when the governance or infrastructure requirements exceed what either framework provides on its own.