Creation of AI agents: constructor, framework or own cycle

What does this solve?

Between “they showed a demo” and “it works for us every day,” there is a choice of tool, and the cost of a mistake here is a wasted month. The creation of AI agents follows three paths: a visual script designer, a code-based framework, and a custom loop on top of the model API. Roads lead to one point, but teams spend their time differently and hit the ceiling differently. Below is what each gives, what it takes away, and what criteria to choose before starting work.

How it works

All three layers have the same core inside: the context goes into the model, the model calls the tool, the code makes the call, the result is returned to the context, the step is repeated. The layers differ in who writes this loop and how much of it is visible from the outside.

Layer 0. Finished agent-product. Code agents in the terminal and editor, agents inside CRM and email services, built-in assistants in trackers. The instruments are already connected, no one is writing a loop. Suitable when the task coincides with the one for which the product is made. Not suitable when you need access to your own tables.

Layer 1. Scenario designer. Nodes on the canvas: trigger, model call, branching, HTTP request, table entry. Tools are connected using ready-made connectors. From this class - n8n, Make, Zapier and agent builders from model and cloud providers.

Layer 2. Framework. A code-based library that provides looping, memory, task transfer between agents and restarts. From this class are LangGraph, CrewAI, AutoGen, Pydantic AI and agent SDKs of the model suppliers themselves. The code is in git, debugged with a regular debugger.

Layer 3. Own cycle. Direct calls to the model API with a tool parameter and a loop in several dozen lines of your code. No abstractions between request and response.

Comparison of what hurts in practice

What transfers between layers

Three things are transferred: tool descriptions, prompts and a set of checks. The bindings - schedules, repetitions, queues, state storage - are not transferred. Therefore, from the very beginning, the tools should be kept separate from the platform: your own HTTP service or a server using the protocol MCP connects to the constructor, the framework, and its own loop. Then moving between layers costs a loop rewrite rather than the entire integration.

Rule: tools and prompts live outside the build platform, otherwise changing a layer means rewriting everything.

How to connect

Route A. Constructor

1. Create a script with a trigger: schedule, webhook or new letter.
2. Connect sources using ready-made connectors, for the rest - an HTTP request node with a token in the platform storage.
3. Install a model call node and describe the tools in it as separate function nodes.
4. Add fault thread: empty data, connector error, timeout.
5. Enable logging of runs and dumping the script to a file - this is the only backup.
6. Run on prepared tasks, put the script on a real trigger only after that.

Route B. Framework

1. Raise the project, fix library versions - agent frameworks change interfaces quickly.
2. Describe tools with typed functions, take the argument scheme from the types.
3. Assemble a graph or sequence of steps, separately separate the data verification nodes between steps.
4. Enable inline tracing and ensure that the trace shows the full model query, not just the total.
5. Write tests for tools using normal language means, separately - running a set of tasks for the agent.
6. Manually collect one request to the model with the same data and compare it with what the framework sent.

Route C. Own loop

1. Take the model API client and enable the parameter with a list of tools.
2. Write a loop: request, parse response, make a call, add the result, iteration limit.
3. Add a rights check before each call and a timeout for the tool.
4. Write a trace to a file or table: step, tool, arguments, response, tokens.
5. Hang the strapping on top: schedule, repeat in case of network failure, task queue.
6. The set of checks is run by the same script as the work tasks, so that the paths do not diverge.

How to choose

Four questions, the answers to which close the choice:

• Who will fix this in six months? Analyst - designer. Developer - code.
• Do you need control over what exactly goes into the model? Need a code.
• Is review of changes and rollback required? Required - code.
• How many such agents are planned? One is a designer. A family of similar ones - a framework or its own cycle with a common library.

Useful scripts

• One-time internal automation for a week: designer, no developer needed.
• Processing mail and requests with branching by type: constructor, while there are few branches.
• Agent going to the combat base: code, because rights and limits are set in the code, not with a checkmark.
• Multiple agents with task transfer to each other: framework, for the sake of ready-made routing and state.
• An agent inside its own product, which clients see: its own cycle, for the sake of predictability and code ownership.
• Prototype for two days before the budget defense: a designer, regardless of how it all ends in production.

Limitations

Constructor. Debugging is based on node logs; the full request to the model is often not shown. Versioning - file export, review of almost no changes. Logic with dozens of branches turns into a canvas that no one reads. Changing the platform means rebuilding from scratch.

Framework. Abstractions hide the most important thing - the final context. Until a way to see the exact request is found, debugging proceeds blindly. Library updates break interfaces, and reading other people's sources becomes a regular job. Some of the model's capabilities remain unavailable until the wrapper is updated.

Your cycle. Everything that is given in the framework will have to be written: repetitions, request rate limiting, state storage, parallel calls, tracing. Savings on the first agent results in your own mini-library for the third.

Common for all. Changing the model changes the behavior of the agent even with the same prompt. A set of checks is needed on any layer; Without it, switching to another model or another layer turns into a lottery.

How to check the result

The same set of tasks on all prototypes. It makes sense to compare layers only on identical inputs and identical instruments, otherwise the formulations of prompts are compared.

View the final query for the model. On each layer, find a way to see what exactly is gone: full text, order of messages, descriptions of tools. There is no way - this is the main argument against the layer.

Measure the build time of the second agent, not the first. The first one is assembled slowly everywhere. The difference between the layers is visible on the second and third, when it becomes clear that there is overuse.

Check portability. Upload the script or code, raise it in a clean environment and run a set of tests. It doesn’t go up - there is no backup, no matter what the platform shows.

Calculate the cost of ownership per month. Platform subscription, tokens, developer time to fix after other people's updates. Count by magazines, not by estimates.