Why I Chose APIs Over an Agent Framework

This analysis examines why i Chose APIs Over an Agent Framework, what evidence supports the argument, and where the conclusion still has limits.

Read the evidence below as a decision trail: what changed, why it matters, which trade-offs shaped the result, and where the conclusion still depends on context.

The previous article dismantled the requirements for cross-language community volume analysis. This article examines the next step: how to grow the system architecture from the requirements and the judgment logic behind each technology selection. Let me start with the conclusion - I did not use any Multi-Agent framework, a four-module linear pipeline plus pure Claude API was enough. This decision itself is the most important content of this article.

Why not use the Multi-Agent framework: linear processes don’t require a graph engine

The first question when designing system architecture: Should I use a ready-made AI Agent framework?

I evaluated three options:

CrewAI。Role-oriented design is intuitive—define several Agent roles, assign tasks, and let them collaborate. GitHub has 45K+ stars, active community, and quick to get started. But after reading the document, my judgment was: My scene was over-designed. My process is linear (collection→analysis→insight→output) and does not require agents to talk to each other or dynamically assign tasks. Using CrewAI is equivalent to introducing a framework for processing complex networks for a straight line.

LangGraph。The strongest process control capability - conditional branching, parallel execution, and breakpoint recovery are all supported. But the learning curve is steep, and even a simple linear process requires defining state schema, nodes, and edges. For projects developed by one person, the abstraction layer of the framework will not speed up development, but will increase debugging costs. When something goes wrong, you have to look for bugs in the abstraction layer of the framework, rather than looking directly at your own code.

Pure Claude API + Python script.This is my final choice. Zero learning cost, complete control, no additional dependencies, just look at input/output when debugging.

There are four judgments behind the decision:

The process is linear.Collect→Analyze→Insight→Output, the input of each step is the output of the previous step, no conditional branching or state backtracking is required. Linear processes use frameworks, such as building a post office to send a letter.
Developed by one person.The value of a framework is to provide a unified abstraction when teams collaborate. When one develops with Claude Code, the abstraction layer of the framework is pure overhead.
LLM costs zero.I subscribe with Claude Max and there is no additional charge for API calls. Frameworks usually have optimization logic to "reduce token consumption", but this advantage does not apply at all under the subscription system.
The value of a portfolio lies in design decisions.What the interviewer is looking for is not whether you can use CrewAI, but whether you can judge "when to use it and when not to use it." Choosing not to use a framework is a compelling design decision in itself.

Analysis and Insights Four Reasons to Split into Two API Calls

The system architecture looks like this:

Collection layer (Python crawler) → Analysis layer (Claude API #1) → Insight layer (Claude API #2) → Report output (Markdown)

One of the design choices needs explanation: Why are analytics and insights two separate API calls, rather than merged into one?

Four reasons:

The nature of the tasks is different.The analysis layer is "processing one by one, structured output" - each piece of community content is individually judged on sentiment, classified topics, and marked with credibility. The insight layer is "global synthesis and output judgment" - integrating all analysis results into trends, comparisons, and action recommendations. The prompt design logic of the two tasks is completely different.
Merging reduces quality.If two tasks are crammed into the same prompt, the prompt will be long and complicated, and the attention of the LLM (large language model) will be distracted, and the quality of both tasks will be reduced.
Intermediate products can be archived.The output of the analysis layer is structured data, and after being stored, the AI’s judgment process can be reviewed. If there is a problem with the conclusion of the insight layer, you can go back to the intermediate product to check whether the analysis layer is wrong or the synthesis of the insight layer is biased. This is very important for debugging.
One more call does not increase the cost.Under the Claude Max subscription system, the number of API calls does not affect the cost. Under this premise, the benefits of splitting far outweigh the little delay saved by merging.

Trooper filtering: Suspicious comments will not be deleted. Delegation is safer than hard deletion.

There are a lot of trolls in App Store and Google Play reviews. If not handled, the analysis results will be seriously contaminated.

I added a fifth analysis dimension to the analysis layer:credibility. Each review is marked as "Trusted" or "Suspicious."

Judgment basis:

Content is too short and samey
Term templated (as if generated from the same template)
Rating contradicts content (gave 5 stars but content is complaining)
A large number of similar comments in the same time period
Lack of product specific content (only general praise or criticism)

There was a deliberate choice in the design:Suspicious comments are not deleted, but are downgraded in the calculation of the insight layer.The reason is that the judgment of trolls cannot be 100% accurate, and short comments that may accidentally kill real users are hard to delete. Downgrading is a safer approach - the influence of suspicious comments is reduced but not reset to zero. If a trend even includes suspicious comments, its signal strength will be higher.

Configuration-driven design: Change the configuration when changing industries without changing the program code

All adjustable parameters are collected in one configuration file. When changing industries, only the configuration is changed, and the core analysis logic remains unchanged:

Configuration of this case:Social media + App Store + Google Play + product information website / local language → Chinese / user sentiment and topic popularity.

If you switch to the technology hardware industry:Social Media + Reddit + Technology Forum / English→Chinese / User Satisfaction and Product Defects.

The separation of the configuration layer and the logic layer means that changing the industry does not require changing the program code, only the parameters such as data sources, language pairs, and analysis dimensions need to be changed. This is the premise of building once and reusing multiple times.

What this means

This architectural design allowed me to confirm a judgment standard:The only criterion for tool selection is "solving problems", not "demonstrating technology".

CrewAI is cool and LangGraph is powerful, but for my scenario they don't make the system better, they just make development slower. Choosing not to use them is not because I don’t understand them, but because I judge they are not needed after understanding them.

The same logic applies to source adjustments. The source of the original plan was more complete, but in the face of the reality of API pricing and anti-crawling, sticking to the original plan would only stall the progress. The goal of MVP is to validate the core value, not to pursue perfect coverage. Those that can be obtained stably will be listed first, and those with risks will be marked for verification in stages.

I have seen too many situations like this in my work: the team spent three months researching framework selection, and finally found that the business needs could be solved with a Python script. That’s not to say that frameworks aren’t valuable — they are necessary when you have complex multi-agent collaboration and require state management and error recovery. But many times, your process is a straight line, and a straight line does not require a graph engine.

Being able to tell "when you don't need it" is more valuable than "being able to use everything".

Technical limitations of sources: API pricing and anti-crawling force MVP scope adjustments

The sources of MVP data for the demand disassembly stage planning are: social media + local forums + app store reviews. After actually starting to do technical research, I hit reality.

Pricing issues for social media APIs.The free version of the official API can only be written but not read — completely unusable for data collection. The price of the paid version ranges from $200/month to $5,000/month, which is unreasonable for a PoC (Proof of Concept) project. Adjustment plan: Use Claude’s search capabilities to crawl directly, at zero cost, but the feasibility needs to be verified.

Anti-crawler mechanism for local forums.Overseas IP restrictions coupled with powerful anti-crawlers make the technical threshold too high. Just give up, it's not worth spending time conquering in the MVP stage.

Adjusted MVP source:

Social media: Switch to alternative crawling methods (feasibility to be verified, listed as the highest technical risk)
App Store (iOS): crawling, independent processing
Google Play (Android): Crawl, standalone processing. The two platforms are separated because their user groups are different and they need to conduct troll filtering independently.
The largest local product information website (730 million monthly views): promoted from an alternative to the first source of MVP due to its high degree of structure and stable data volume

The judgment logic here is:The goal of MVP is to verify whether the core link "from data to insights" is valuable, not to pursue the integrity of data sources.Sources that can be obtained stably are listed first, and those with high technical thresholds are deferred.

Five technical risks, social media crawling feasibility ranks first

Every design decision has risks. List them in advance to know the priority of verification:

Highest risk: feasibility of social media scraping.Whether the alternative solution can obtain data stably has not yet been verified. This is the first thing to test when entering the development stage - if this path does not work, you need to find an alternative immediately.

Medium risk: Misjudgment of local language sentiment.The expression of the target language is highly dependent on context, and the same sentence may have completely opposite emotions in different situations. It is necessary to adjust the prompt for high-frequency misjudgment mode after actual measurement.

Medium risk: Store review spam ratio.If the proportion of trolls is too high (for example, more than 50%), the remaining sample size of real comments after downgrading may not be enough to generate meaningful insights.

Low risk: Changes in the structure of the product information website.The crawler relies on the structure of the web page, and structural changes require updating the crawler. However, the structure of this website is stable and the short-term risk is low.

Low risk: Insufficient data on unlisted competing products.There are already few community discussions on unlisted products, which may not be enough to produce meaningful analysis. But this is acceptable at the MVP stage—how much data to analyze.

Practical questions and boundaries

Under what circumstances would a pure API solution be insufficient?

When the process changes from linear to non-linear. For example: Agents need to transfer information to each other to make dynamic decisions, if a certain step fails, they need to automatically roll back and retry, and multiple analysis tasks need to be executed in parallel and the results merged. In these scenarios, the framework's state management and process control capabilities are of real value. My system is currently linear, but if I want to add logic such as "dynamically deciding whether to investigate a topic in depth based on the analysis results" in the future, it will need to be re-evaluated.

Is the AI judgment used by trolls for filtering accurate enough?

The accuracy of each article alone will not be 100%, but it is enough at the system level. The reason is that I don't rely on judgment alone to make decisions - the weight reduction mechanism allows a small number of misjudgments to not affect the overall insight. Moreover, the pattern of trolls is usually batch (a large amount of similar content at the same time), and this pattern is easy for AI to identify. What is really difficult to judge is the gray area between reality and fake content, but these contents should not have too high a weight.

Why are reports made in Markdown instead of Dashboard?

The priority of the MVP stage is to verify "whether the insight content is valuable", not to verify "whether the presentation method is good-looking". Markdown produces the fastest and is easiest to view and modify. If insight content verification is valuable, it’s not too late to invest in Dashboard. On the other hand, it is useless to make a beautiful Dashboard without insight into the content, that is, decorating a house without a foundation.

What to take away

The useful decision is not to accept the headline at face value, but to test whether the evidence supports i Chose APIs Over an Agent Framework in the reader's own context.