AI Agent Development Frameworks: What a Small Business Actually Needs and What We Skip
Which AI agent framework should a small business pick, and when does a strict tool schema, explicit routing and a non-AI fallback matter more? A practical answer from the people who ship these systems.
For most small businesses, the right pick among ai agent development frameworks is the thinnest one: a vendor SDK (Anthropic or OpenAI) with strict tool schemas, explicit routing in code and a non-AI fallback. Add an orchestration framework only when state, retries or branching outgrow plain code.
The short answer on ai agent development frameworks
Frameworks get the attention because they are visible. You can star a repo, read a quickstart and feel like you made a decision. The decisions that decide whether an agent survives its first month in production are less photogenic: what the model is allowed to call, who decides which path a request takes, and what happens when the model is unavailable or wrong.
Take our own lead acknowledgment agent on triminage.com. A rule-based spam filter runs first. Code, not AI, picks the most relevant case study. Claude Haiku then writes a short reply that links that case study and a booking page, with free slots read from Google Calendar. That is a pipeline with one model call in the middle. A framework for building ai agents would have added a dependency and a graph to draw, and nothing else. The value sits in the filter, the matching code and the stop conditions (sending halts on booking, unsubscribe, bounce or a won or lost deal).
So the honest order of operations is: schema, routing, fallback, then framework. Most small-business workflows never get to the last step.
What changes the answer
Plenty of search results lump together ai agent frameworks, SDKs, workflow builders and hosted platforms. They solve different problems. Four questions separate them in practice.
How many steps, and how much state?
A single model call that returns structured output needs no framework. A loop that calls two or three tools and stops is still a few dozen lines against the vendor SDK. Once a run takes minutes, pauses for a human, resumes after a crash or carries memory across sessions, you are rebuilding a state machine, and an agent orchestration framework starts to pay for itself.
DejaThink is the case where a graph earned its place. It is an AI companion with persistent memory, a solo chat, a team chat where the AI takes part live, and a goal-driven mission mode. It runs on an orchestration graph with a model-as-judge completion check, and the user approves or rejects each memory before it is saved. That is a product, built over about 15 weeks by a team of 3, not a back-office helper.
Who decides where a request goes?
This is where we have been burned. We tried provider-managed multi-agent delegation, where you hand the model a roster and let it hand work off. In weeks of use it never handed off once, and the chair agent invented errors to explain itself. Explicit routing fixed it. In our multi-agent advisory board prototype (a chair plus eight functional advisors), one routing call picks who answers, the advisors answer in parallel, and each sees what the others said. The routing is a single, inspectable decision, not emergent behavior.
If your framework's headline feature is autonomous delegation between agents, test it against your real requests before trusting it. If routing can be a switch statement or one classification call, write it that way.
What does the model touch, and how strict is the contract?
Of all the ai agent development tools we use, the strict tool schema does the most work. The model must call one tool or answer against a JSON schema, and free text never feeds another system. The client's real categories, tags and options go into the schema as allowed values. Code carries facts such as prices, links, categories, permissions and counts; prompts carry judgment.
There are gotchas no framework will save you from. Strict tool schemas can reject keywords like minItems and maxItems. We added them once and every production call broke, so counts are now checked in code. When a call fails validation, the retry sends the model the reasons it was rejected. Without those reasons, all three attempts failed the same way.
Who maintains it in a year?
Frameworks in this space change quickly: LangGraph, CrewAI, AutoGen, the OpenAI Agents SDK, the Claude Agent SDK and the Vercel AI SDK all evolve their abstractions on their own schedule. Every one is a reasonable choice for some team. The cost is that your small business now owns an upgrade path for a layer that a vendor SDK call would not have needed. If the person maintaining the agent is a part-time developer or an agency you may change, fewer moving parts is a feature.
What orchestration actually means in production
Even when we use no framework, orchestration still exists. It just lives in ordinary code, and the failures it prevents are mundane. Scheduled jobs are protected by a secret and made idempotent, using unique keys, input hashes and an already-done-today check. Long work runs as resumable steps under a 10-minute lease. A global concurrency cap stops a traffic spike from spawning unlimited functions. Running out of tokens is treated as a failure, never a partial result.
Each of those came from something that broke. A failed email once still recorded its sent key, so it was never retried. A misconfigured job reported success in under a second with nothing produced, so our agents now fail loudly. Three scheduled agents had no shared spend cap, and one paid endpoint was public because its secret was unset. None of these are framework questions. If a framework hides them from you, check what it does instead.
The non-AI fallback belongs in the same category. Every agent we ship has one. If the model is down, lead emails fall back to templates and SEO briefs fall back to a template engine, and the output says which engine produced it. Our AOF account-opening product goes further: it has no model in it at all. Guided forms, validation before submission, OTP verification and document upload, with the broker's compliance team approving each application. For a lot of intake work, rules are the right answer, and the clean, validated data they produce is what an agent would need later anyway.
How to decide and plan the work
If this is a decision you have to make this quarter, work through it in this order. The framework choice is step six on purpose.
- Name one workflow, one owner and one metric that decides go or no-go. If you cannot name all three, you are not ready to build, and no framework changes that.
- Measure the current path before touching anything: median and slowest-case time per case, rework rate, queue depth and cost per case. Without a baseline you cannot prove anything afterwards.
- Write the tool schema first. List every action the agent may take, with allowed values pulled from your real systems (CRM stages, store categories, calendar slots). Anything irreversible stays a draft for a person to approve.
- Write the routing as code. If a rule can pick the path, use the rule. Use a model call for routing only where the inputs are genuinely messy, and log which path was chosen.
- Build the fallback. Decide what the business does when the model is slow, down or rejected by your checks, and make the output label which path ran.
- Now choose tooling. A vendor SDK is the default. Consider an agent orchestration framework if you need durable state, pause and resume, or branching you would otherwise hand-roll. Ask whether you can read its traces, pin its version and remove it later without rewriting your tools.
The trade-off is real in both directions. A framework gives you tracing, persistence and a shared vocabulary, and costs you abstraction you must learn and upgrades you must absorb. Plain code gives you total clarity and costs you the state handling you will eventually write yourself. For a single workflow with a handful of tools, plain code usually wins. For several long-running agents that share memory, the framework usually wins.
On timing, a narrow single-agent sprint typically takes 1 to 2 weeks, and a focused single-workflow pilot with baseline and shadow mode typically runs 2 to 6 weeks. The driver is how many systems the agent touches and how strict its checks are. Production versions of a new agent take weeks, not days. We have shipped a working multi-agent prototype in two days, but that is a prototype and we treat it as one.
On cost, we quote each engagement after a short call about the workflow. The drivers are integrations, the review flow, data access and how strict the checks must be. Running costs per task are small and we estimate them during the pilot, mostly as a function of how much text goes in and out and which model handles it.
Earn autonomy in shadow mode
Whatever tooling you pick, start with the agent drafting and people approving. Our pilot plan spends week four in shadow mode, tuning on real traffic, and moves to partial autonomy only where the gate is mechanical and a failure is cheap. Two weeks of shadow mode costs less than months of quiet non-adoption.
Where a delivery partner fits
A partner earns its place in the unglamorous parts: connecting to the CRM, inbox, store or help desk you already pay for, designing the review step, and making the thing fail loudly. Our AI agent development service works one workflow at a time, with human review built in, and hands over an in-repo knowledge base of dated decisions and gotchas so your team is not dependent on us to understand it.
If you are still deciding whether an agent is the right shape for the problem at all, the guide to AI agents for small business covers where they fit and where a rule or a template is better. For a sense of what a finished workflow looks like, our own sales pipeline is the closest example: lead acknowledgment and scheduling on one side, job-alert triage and proposal drafting on the other. In the second, Claude Opus rates each incoming job for fit and posts a card to Slack, but a person picks the job and submits every draft, because the platform does not allow bots. We never automate around a platform's rules.
The framework conversation is easier once those pieces exist. By then you know what state you need, how many steps a run takes and who will maintain it, and the choice is usually obvious.
If this is on your roadmap, tell us what you are trying to ship and we will map a concrete next step.