Build a custom agent
for any small business.
Fill out the intake once. The factory assembles a system prompt, wires the tools, and emits a runnable Claude Agent SDK project — in TypeScript or Python. Everything below regenerates live.
Client intake
Generated project
What agent-factory does
agent-factory turns one intake form into a working AI agent for a small business. You describe the business in plain language — what it does, how it should sound, what it is allowed to do, who to escalate to — and the factory assembles a complete Claude Agent SDK project around that description: a system prompt, tool definitions, permission settings, an eval suite, and the runnable source files, in TypeScript or Python.
It exists because most small-business agent work is the same work repeated. A dental office, a solar installer, and a landscaping company all need an assistant that answers common questions, captures a lead, refuses to invent facts, and hands off to a person when it is out of its depth. The differences between them are content, not architecture. agent-factory holds the architecture steady and lets the content change, so building the tenth agent takes minutes instead of days.
How the pipeline works
1. Intake
One form is the source of truth. Business name, industry, the agent's role and tone, what it can help with, the guardrails it must never break, facts it can rely on, and who it escalates to. Everything the generated project contains traces back to a field on this form, so there is one place to change when the client changes their mind.
2. Generate
Picking a pattern — Support, Ops, or Mixed — layers proven defaults over your intake. Support agents get customer-facing guidance, a locked-down permission mode, and baseline rules like never collecting card numbers. Ops agents get staff-facing guidance, file tools, and a rule against deleting anything without confirmation. Mixed agents figure out which mode they are in and adjust. Your own guardrails are merged on top of the pattern's baseline, never replaced by it.
3. Customize
Custom tools are declared by name, description, and typed parameters. The factory emits each one as a real, correctly-typed tool stub — Zod schemas in TypeScript, type annotations in Python — with a TODO body where the integration goes. Wiring the agent to a CRM, a booking system, or an internal API means filling in a function, not designing the plumbing.
4. Eval
Every generated project ships with an eval harness and a starter case file. Before an agent goes near a real customer you can run it against the questions it will actually be asked and see where it guesses, over-promises, or fails to escalate. Prompt changes get checked against the same cases, so tuning one behavior does not quietly break another.
5. Handoff
The output is an ordinary project directory the client can own: source files, the system prompt as a readable Markdown file, an environment template, and dependency manifests. There is no runtime lock-in and nothing hidden — the prompt the agent runs on is a file you can read and edit.
What you get in the generated project
system-prompt.md
The full prompt in readable Markdown — identity, capabilities, rules, escalation policy, and known facts — kept as a file so it can be reviewed and edited by a non-programmer.
agent.ts / agent.py
The runnable entry point: model selection, allowed tools, permission mode, and an ask()
function you can call from a script, an API route, or a chat widget.
tools.ts / tools.py
Typed stubs for every custom tool, registered on an SDK MCP server and scoped so the agent can only reach the tools you granted it.
eval.ts / eval.py + cases
A test loop for agent behavior, so prompt edits are verified against real questions instead of judged by vibe.
Try it before you commit
The Test agent tab runs your configuration against the real model with the exact system prompt shown on this page. Custom tools respond as stubs, so you can watch when and why the agent decides to call one without connecting anything first. Change the tone or a guardrail on the left, send another message, and the difference shows up immediately — this is the fastest way to find out that a prompt reads well but behaves badly.
Who this is for
- Operators and consultants building agents for local clients who need something dependable rather than a demo, and who need to hand the result over and walk away.
- Developers who want the Claude Agent SDK scaffolding — prompt structure, tool registration, permission modes, evals — laid out correctly once instead of re-derived per project.
- Small business owners who know exactly how their front desk should answer the phone and want that written down as an assistant that follows the rules.
Common questions
Do I need to know how to code?
Not to build and test an agent here — the intake form and the live preview are the whole loop. Taking the generated project to production does take a developer, or someone comfortable running a Node or Python project and filling in the tool stubs.
What stops the agent from making things up?
Three things, all visible in the prompt: the facts list is the only ground truth it is told to rely on, the rules section instructs it to say plainly when it does not know, and the escalation section gives it a person to hand off to. None of that is a guarantee, which is why the eval harness ships with the project.
Which permission mode should I pick?
For a public, customer-facing agent, dontAsk — no write access, nothing to approve. For internal staff tools, acceptEdits keeps a human in the loop on anything that changes data. plan is read-only and useful while scoping. Pick the most restrictive mode the job allows.
Is it TypeScript or Python?
Either. The same intake produces both; the language toggle changes the emitted files, not the agent's behavior. Pick whichever the client's team already maintains.
New to this? The operator course walks through writing a system prompt, wiring tools, running evals, and handing a finished agent to a client.