The agent reviews ten products out of a hundred because the tool returns "up to 15 results," and the table provided to the model gets truncated. Developers have previously discussed building a marketplace AI manager using regular expressions, then migrating it to an agent immediately constrained by rigid limits: eight steps per turn, narrow tools with caps, trimmed data, and backend writes executed only after owner approval.
Attempts to build a proprietary AI agent core with rigid limitations lead to an operational dead end and a forced transition to off-the-shelf frameworks. Developers do not disclose exact financial losses, but the scale of the engineering gridlock is evident in the codebase that had to be completely rewritten after failed tests. Building a custom orchestration engine requires constant capital expenditure to maintain execution cycle infrastructure, error handling, state serialization, and context management. When a team reinvents the wheel for call orchestration instead of leveraging established libraries, it systematically burns budget on infrastructure tasks already solved in specialized packages.
The hidden costs of custom development extend beyond engineering hours spent writing infrastructure code to include ongoing maintenance liabilities. Each external API update—whether modifications to marketplace schemas or new security requirements—forces teams to rewrite wrappers, custom parsers, and step-handling logic. Consequently, supporting a proprietary core begins to consume engineering resources earmarked for product logic and business metrics. The engineering department becomes hostage to its own codebase, where fixing a single bug in the agent loop triggers three new failures in adjacent modules.
The Illusion of High Benchmark Scores
Initial tests indicated formal success: a judge model assigned answers scores from 1 to 5 based on the data visible to the agent.
The agent outperformed legacy phrase parsing across seven out of nine job roles, with the marketplace manager role scoring 4.28.
Subsequent manual audits of interaction logs revealed a different reality. The agent delivered confident yet superficial answers, which the judge model failed to catch because the data visible to the agent aligned with the output conclusion. Restrictions such as the eight-step limit undermined long-running tasks, such as analyzing niche sales drops, where the agent lacked sufficient instructions for deep analysis.
Migration to Standard Frameworks
Building a custom core provided granular control over agent logic and execution steps, shielding the system from the unpredictable behavior of standard frameworks, until developers hit a maintenance wall with their proprietary loops. The economic imperative of migrating to off-the-shelf solutions becomes apparent the moment a company calculates the total cost of ownership for a custom engine. Maintaining a proprietary execution infrastructure, writing custom answer validators, and debugging agent states demand hundreds of hours of high-cost, skilled developer labor.
therefore we deleted our entire core and migrated agent execution to Pydantic AI.
According to the project authors, four days after the launch, they completely deleted their agent. The resulting commit showed 582 lines removed and 121 added. Instead of dozens of wrappers for individual Wildberries methods, the agent received the wb_help tool—official documentation for them.
How many more teams will spend weeks writing custom step-handling loops before recognizing the economic inefficiency of maintaining proprietary code?
Why it matters
Why do engineering teams keep building custom engines for AI agents when the illusion of full control quickly collapses under real-world workloads? The creators of an AI marketplace manager tried to guard against unpredictable framework behavior by imposing strict eight-step limits and truncated tool data. The strict eight-step limit kept the custom system entirely safe from misbehavior, as well as from doing any actual analysis.