The Seven "Not A, But B" Points in Tencent Cloud ADP Course Materials: A Checklist of Trade-offs for Enterprises Deploying AI Agents

I came across a copy of the "Tencent Cloud ADP Forward Deployed Engineer (FDE) Course Materials": from the fundamentals of AI and Agents, to ADP product capabilities, to developing agents with ADP, and then to evaluation and optimization—it covered the whole story of "how enterprises actually build agents and put them to use." After reading it through, what struck me hardest was not where some button is or how some parameter is configured, but the same sentence pattern that appeared over and over throughout the whole text—

"Not A, but B."

I counted them, and the density was abnormally high. More importantly, almost every one of them was correcting a mistake that enterprises make every day but that nobody takes seriously. So I organized them, paired them with comparisons from my own data governance projects, and wrote this piece.

1. It's not that the technology is too hard; it's that the terminology is too messy

The opening line of the materials is: "Most people's confusion about AI is not that some technology is too hard, but that there are too many terms and the relationships are too messy." The solution it offers is just one diagram plus one timeline: artificial intelligence ⊃ machine learning ⊃ deep learning ⊃ generative AI, four circles nested layer by layer; and in terms of development, it goes from "can recognize" (1950s–1990s, handwritten digit recognition), to "can judge" (1990s–2016, recommendation, risk control, credit scoring), to "can create" (after the 2017 Transformer, ChatGPT surpassed 100 million in two months).

Why is this valuable? Because it punctures an organizational phenomenon: when enterprises argue about "whether to adopt large models," they often have not even clarified "which layer we are actually talking about." In project proposals, "generative AI," "large models," "Agent," and "intelligent agent" are used interchangeably, and the first page is already off; afterward, budgets, acceptance, and responsibility attribution all go off along with it.

If the terminology is not aligned, the budget will not be aligned.

2. It's not that the model is not smart; it's that it only does "word chaining"

The materials put it very bluntly: "A large language model essentially only does word chaining." Give it a piece of text, predict what the next token is most likely to be, append it; read it again, append another—each step is choosing the one that "reads most smoothly" in the same multiple-choice question.

This inevitably brings out two problems: hallucination (it is only responsible for fluency, not for verifying facts, and will even accept it wholesale if a tool returns "the temperature in Shanghai is 10,000 degrees") and knowing nothing about "the present" (it does not know who it is or what time it is now, knows nothing after the training cutoff date, and there is also an upper limit on the context window length). The materials also casually point out a common measurement fact: the smallest unit of text in the model's eyes is the token, not the character; invocation cost and how much can be processed are all calculated by token.

So "switch to a bigger model" is often the wrong direction for solving the problem. The correct answer given by the materials is to fill in five shortcomings:

The materials also have a footnote I quite like: the high-dimensional vectors of Embedding actually learned analogical relationships—"teacher − school + hospital ≈ doctor," "Paris − France + China ≈ Beijing." When enterprises build a knowledge base, they are essentially preparing these "coordinate points" for RAG.

Fluent ≠ correct. The model does not need to become smarter; it needs its shortcomings filled in.

3. It's not about opening the platform and building an application; it's about first judging whether it should be built

This is the line in the whole piece that I think most deserves to be pasted on the wall: "When doing an agent solution, the first step is not to open the platform and build an application, but to first judge: whether this business problem can be handled stably by AI, which ADP mode should be used to carry it, and what results will prove after implementation that it is truly effective."

Three questions are actually a checklist that can be copied directly into a project proposal template:

And what is most easily overlooked is the reminder immediately following in the materials: "Many real projects do not choose only one mode, but combine them in stages." It gives the example of a hotel intelligent service assistant: in the first phase, use the standard mode to answer hotel information and service facilities; once the processes of "guest requests for item delivery, order modification, maintenance repair requests" are fixed, then use workflows to string together parameter collection, work order generation, and result notification; only later, when business analysis and service optimization are needed, introduce Multi-Agent or Claw.

This sentence carries a strong sense of trade-off—starting with the most complex architecture right away is not forward-looking; it is a failure to think clearly.

First ask "should it be done, and how will it be accepted," then ask "how to build it."

4. The most dangerous thing is not slow answers; it is "not knowing but pretending to know"

The materials say: "In enterprise applications, the most dangerous thing is not 'slow answers,' but 'not knowing but pretending to know.'" The solution is to configure refusal: when materials are insufficient, the question is out of scope, or the risk is relatively high, clearly state that it cannot be confirmed and guide the user to supplement materials or contact the person in charge.

Its positioning of the "enterprise knowledge exploration assistant" is also written very restrainedly: "It is not an all-purpose chatbot, but... when a question exceeds the scope of knowledge, it will clearly refuse to answer, avoiding fabrication."

This point is most devastating for people doing data governance. Because inside an enterprise, an AI fabricating a policy clause is not a technical issue at all; it is a responsibility issue—who endorses this answer? If an employee submits an expense reimbursement according to it, whose fault is the miscalculation? The materials classify it as "configuration"; I would rather classify it as "governance": this is the traceability of answers and the boundary of responsibility, the same thing as what we do with data quality and defining data owners.

Only when you allow it to say "I don't know" will you dare let it into production systems.

5. It's not a demo toy; it needs to have all "six abilities"

The original sentence in the materials: "Enterprise-grade Agents are not demo toys; they need to enter real business systems. Therefore, they must have controllability, testability, auditability, operability, reusability, and integrability."

Its business example for "controllability" is especially concrete: when an Agent finds that customer information is to be deleted, it must wait for human approval rather than executing automatically. Testability requires complete logs, reproducible problem scenarios, clear success criteria, and a test environment.

Now compare these six words with the old sayings in our field: controllable, testable, auditable, operable, reusable, integrable—isn't this just data governance's "data controllability, traceability, auditability" in a new outfit? Agent governance is not a new discipline that appeared out of thin air; it is an extension of data governance to "systems that can act autonomously." The only difference is: in the past we governed static data, now we govern behavior that calls tools and runs processes on its own.

This is also why the materials answer "why you cannot rely on Prompt + open-source models fighting alone": these characteristics must be integrated by a platform and be ready out of the box, so ADP is positioned as "not an ordinary Chatbot, nor a single large-model interface, but a production and operations platform for enterprises to build agent applications."

Demos show the effect; going live depends on these six words.

6. It is not built in one go; it is run out through "debugging—optimization—evaluation—regression"

The materials write: "A stable agent is not built in one go; it gradually stabilizes through continuous debugging, optimization, and regression." They also specifically distinguish two things that are often conflated—"agent debugging and evaluation are not the same thing. Debugging is more like 'fixing while building,' evaluation is more like 'phase acceptance.'"

The comparison it provides is worth screenshotting directly into your project weekly report:

One-sentence summary: "Single debugging and batch evaluation are not substitutes for each other; they connect in sequence." The materials also repeatedly emphasize that "going live is not the end point, but entering continuous operations and iteration."

Going live is not the end point; it is entering continuous operations.

7. It is not that the finer the split the better; it is about letting each fragment independently support an answer

This one is last because it is almost exactly the granularity design question of data governance. The original sentence in the materials: "A Chunk is the basic fragment hit during knowledge retrieval. The goal of chunking optimization is not to pursue finer and finer splits, but to make each fragment revolve around a relatively complete question: it is easy for user questions to hit, and it provides enough context for the model to answer."

It gives a very useful criterion: check whether the hit fragment itself "can independently support an answer." If only the conclusion is hit but there are no conditions, only table data but no header, or only process steps but no prerequisites—when these three situations appear, the chunking is not tuned correctly.

The exercises in the materials lay out medical records directly:

The second item is especially worth pondering: "position conditions" and "approval rules" must be in the same context—isn't this exactly the integrity constraints, master data associations, and metadata definition unification we have done for years? When discussing knowledge base quality, the materials also specifically list "institutional/policy content: split by topic, retain versions, open citation sources."

So stop saying vaguely that "AI answers inaccurately because the model is not good enough." Eighty percent of the time it is because the knowledge is not well organized: conditions and conclusions are split apart, versions are not retained, sources are not opened. The materials put it even more bluntly in 4.2: "Poor Prompt results are usually not because a certain sentence is not long enough, but because key elements are missing in the task, basis, boundaries, format, context, or model configuration"; and they remind that "a template is not fixed wording, but a checklist."

Four weapons for fellow data governance practitioners

The seven items above are not for looking at; they are for using. Mapped to our field, there are four things that can be put directly into templates:

Weapon one: write the "three-question checklist" into the AI project initiation template. Can it be processed stably by AI / which mode should carry it / what result proves it is effective. If the three questions are not answered completely, the proposal does not enter review. This one item can block a large portion of the muddled accounts of "the leader says we need to deploy an Agent."

Weapon two: turn the "six abilities" into a go-live gate checklist. Controllable, testable, auditable, operable, reusable, integrable—check each one off; if one is missing, it does not enter production. Pay special attention to the line in "controllability"—actions involving deletion, modification, or external sending must retain human approval.

Weapon three: write "evaluation set + regression" into acceptance clauses. Do not accept "going live means acceptance." Require the delivery party to provide the evaluation set, the pass-rate definition, and regression records after each revision. This turns "going live is not the end point" into contract language.

Weapon four: recognize that your old line of work is the foundation. Chunk splitting = data granularity design; conditions and conclusions in the same context = integrity constraints; retaining versions and opening citation sources = data traceability and lineage; refusal configuration = the responsibility boundary of answers. Those actions in the materials that look like "new AI work" are, when broken down, all familiar data governance work. The accuracy ceiling of an Agent lies in the knowledge you have governed.

Final words

This material goes all the way from AI fundamentals, ADP product capabilities, and development practice to evaluation and optimization, but it is really only talking about one thing: how to turn a "model that can chat" into a "business system that can enter production systems."

And the most valuable part in the middle is not where any button is, but these seven "not A, but B" statements—each one is a trade-off: do not switch to a larger model, fix the weak points instead; do not build the application first, first judge whether it should be built; do not pursue fast answers first, first allow it to refuse to answer; do not pursue a good-looking Demo, gather the six abilities instead; do not accept going live as acceptance, run evaluation and regression instead; do not split knowledge as finely as possible, let each fragment independently support an answer instead.

The materials break this chain into a path that can be learned, practiced, and tested (4-part course + hands-on labs + certification exam). And people who understand data governance are exactly the group with the strongest foundation for learning FDE—because you have long known that whether a system can be trusted never depends on how well it talks.

This article comes from the WeChat public account "Data Driven Intelligence" (ID: Data_0101), author: Data Governance, published by 36Kr with authorization.